Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bazel 2.0

blog.bazel.build

Post reply on HN
Print view View original

11–20 of 117 posts

Re: Bazel 2.0

#11

Post by k__ »

ivanbakel wrote: post #7
kryptiskt wrote: post #3

Earlier quoted context omitted.

That "changed some corner cases that likely won't affect you" and "rewrite it all" looks the same in SemVer makes it next to useless, not that any other system would be better. We just shouldn't have any expectations about version numbers conveying much information.

How is SemVer next to useless? The major version bump informs you that you should go look up what breaking changes have occurred before you upgrade. It is inherently useful for under-approximating the "safe" range of versions of a piece of software that can be used, which is seen in practice in many package managers. That it can't differentiate between those two cases is because it's not meant to. It's like complaini…

SemVer isn't useless because of major bumps, but because of the minor and bugfix.

Theoretically every version change can introduce a bug, which leads to an implicit API change and as such require being a major version bump.

Also, fixing a bug can also introduce an API change, because the API can behave differently with and without the bug.

SemVer just covers the intent, not what's actually happening, which makes it kinda useless in most scenarios. I guess Elm gets it right, tho'.

Re: Bazel 2.0

#12

Post by brudgers »

kylecordes wrote: post #2

As with many projects using semantic versioning, the major version bump just signifies there are some breaking changes. Most projects will just switch from 1.x to 2 work noticing.

Bazel 1.0 was released on October 10. Not much more than two months ago. At best, semantic versioning expresses the intent to break existing code. It's an anti-pattern. It's not a feature. Projects using semantic versioning are explicitly caveat emptor.

Re: Bazel 2.0

#13

Post by ddevault »

For anyone thinking about Bazel for their project/organization... run as fast as you can in the opposite direction. It's easily the most complex and unintuitive build systems in the world, and I'm saying that as someone who used SCons. At the last job where I used it, I was on a team of 5 whose responsibilities included Bazel upkeep, which required anywhere from 10 to 50% of our time. This was used by a broader engineering team of 50, working on 3-5 "big" projects and a few dozen small ones.

Re: Bazel 2.0

#14

Post by sorokod »

kryptiskt wrote: post #3
kylecordes wrote: post #2

As with many projects using semantic versioning, the major version bump just signifies there are some breaking changes. Most projects will just switch from 1.x to 2 work noticing.

That "changed some corner cases that likely won't affect you" and "rewrite it all" looks the same in SemVer makes it next to useless, not that any other system would be better. We just shouldn't have any expectations about version numbers conveying much information.

Semver provides low resolution data on the nature of a change in a release in an easily comprehencible format.

Re: Bazel 2.0

#15

Post by zellyn »

ddevault wrote: post #13

For anyone thinking about Bazel for their project/organization... run as fast as you can in the opposite direction. It's easily the most complex and unintuitive build systems in the world, and I'm saying that as someone who used SCons. At the last job where I used it, I was on a team of 5 whose responsibilities included Bazel upkeep, which required anywhere from 10 to 50% of our time. This was used by a broader engin…

If you are an organization with a large enough codebase (especially if it's in a monorepo) that you need a shared remote cache of build artifacts, or remote build sharding and execution, and have multiple languages (even protocol buffers) interacting in complex dependencies, then you should run as fast as you can away from less rigorous Blaze-alikes (Pants, Buck, etc.) straight towards Bazel.

Yes, it's complicated, but it's also quite rigorous, and the rigor pays off.

(We at Square had already found a Blaze-alike necessary. We are currently busy converting our Java build from Pants to Bazel.)

Re: Bazel 2.0

#16

Post by gravypod »

ddevault wrote: post #13

For anyone thinking about Bazel for their project/organization... run as fast as you can in the opposite direction. It's easily the most complex and unintuitive build systems in the world, and I'm saying that as someone who used SCons. At the last job where I used it, I was on a team of 5 whose responsibilities included Bazel upkeep, which required anywhere from 10 to 50% of our time. This was used by a broader engin…

I've only experienced issues when using bazel with third party package management systems. If you can own all of your source it, and it's descendants, are easily my favorite build systems. It's features complement modern software development in a very ergonomic way: uniform build language, API for learning about your source, testing your entire code base in every language with one command, hermetic and reproducible builds, distributed builds, and caching I can actually trust.

Using Bazel with external packages on the other hand is one of the most tedious and frustrating endeavors imaginable. If you can vendor all of your source it's much less frustrating. This is extremely manageable in the C and C++ worlds where there aren't really any package mangers and you end up needing to do that anyway.

Re: Bazel 2.0

#17

Post by steeve »

ddevault wrote: post #13

For anyone thinking about Bazel for their project/organization... run as fast as you can in the opposite direction. It's easily the most complex and unintuitive build systems in the world, and I'm saying that as someone who used SCons. At the last job where I used it, I was on a team of 5 whose responsibilities included Bazel upkeep, which required anywhere from 10 to 50% of our time. This was used by a broader engin…

To each their own I guess.

I’ve been using it for the last 2 years, and I am not doing any project again without it.

Bazel is not that complex if you start a project with it. Migrating to it and learning it at the same time will be hard though since you’re likely to uncover a lot of skeletons.

Re: Bazel 2.0

#18

Post by simfoo »

ddevault wrote: post #13

For anyone thinking about Bazel for their project/organization... run as fast as you can in the opposite direction. It's easily the most complex and unintuitive build systems in the world, and I'm saying that as someone who used SCons. At the last job where I used it, I was on a team of 5 whose responsibilities included Bazel upkeep, which required anywhere from 10 to 50% of our time. This was used by a broader engin…

Pretty much the same experience. 2y old monorepo company with >150 engineers now, being slowed down by hacks upon hacks in the usage of the bazel build system with around 5 people at the company understanding how bazel works. And those people are discouraged quickly when trying to improve things because of the shear brittleness of the existing build files and "optionated" approaches in the community that don't quite cut our usecases. Even things like enabling remote caching and execution take many months (and even external companies) and still drag on.

Edit: I don't want to come off as too negative about Bazel. But I really think it needs more time and is nowhere near something that I would call a 1.0 let alone a 2.0

Re: Bazel 2.0

#19

Post by lonelappde »

kylecordes wrote: post #2

As with many projects using semantic versioning, the major version bump just signifies there are some breaking changes. Most projects will just switch from 1.x to 2 work noticing.

It's just a few config flag flips.

This is a bizarre naming. They could call it Blaze installer 2.0 for Blaze 1.

Re: Bazel 2.0

#20

Post by afarrell »

k__ wrote: post #11
ivanbakel wrote: post #7

Earlier quoted context omitted.

How is SemVer next to useless? The major version bump informs you that you should go look up what breaking changes have occurred before you upgrade. It is inherently useful for under-approximating the "safe" range of versions of a piece of software that can be used, which is seen in practice in many package managers. That it can't differentiate between those two cases is because it's not meant to. It's like complaini…

SemVer isn't useless because of major bumps, but because of the minor and bugfix. Theoretically every version change can introduce a bug, which leads to an implicit API change and as such require being a major version bump. Also, fixing a bug can also introduce an API change, because the API can behave differently with and without the bug. SemVer just covers the intent, not what's actually happening, which makes it k…

> SemVer just covers the intent, not what's actually happening

If I say "I'm leaving the office to get a sandwich", that statement only covers my intent. If I then sprain my ankle badly, my statement doesn't say what's actually happening.

SemVer has this flaw because it is a way for a human to say "this change does not introduce a change to the API" and that human can be wrong. That seems to me not useless, it just means it is only useful for projects who are willing to trust the maintainers of your dependencies to avoid being wrong about introducing bugs.

--------

It seems like you're arguing that a project which uses a dependency should:

1) Have humans check the dependencies anyway.

or

2) Wire up their automated test suite to something which can record calls to the API of the dependency and the results of those calls. Turn the record of those calls into an set of API contract test cases. Then, on any version bump (minor, major, or patch), run those autogenerated test cases on the new version.

... I think option 2 might be a good idea? It could be a required reviewer for any dependabot PR.

Post reply on HN