> classic problem we have in Bazel land

Can you tell me more about this? I’ve never used Bazel. I have used Buck extensively. But have never used either in an open source context.

▲

rtpg 3 hours ago | parent [-]

there's a wonderful blog post about this that I wish I could find and can't. I feel like it was a github gist.

The gist of it is something like:

- Bazel community hits a problem with something like how npm behaves around paths

- Bazel's solution is to create a patching system around paths to resolve them

- rinse and repeat for every piece of tooling us "normies" are using

The end result is that instead of Bazel's efforts showing up in the base tooling, they build up a bunch of their own tooling and patches, and the underlying tools don't get really much if any benefit. Moving to Bazel still is a PITA, and there's a lack of improving onramps

In an alternate universe when people in Bazel land hit issues they would show up with patches and recommendations _to the underlying tools_ to get things merged in so that the workflows can be better supported across the board.

I don't think anyone working on Bazel is against upstreaming, but I think they discount the value of it because, hey, _they_ can get patches and hacks working for their flow

▲

forrestthewoods 3 hours ago | parent [-]

Ah interesting, thanks.

My intuition is that npm, cargo, zig build etc are all “wrong”. And that Bazel/Buck are architecturally correct. Build systems should be polyglot by default! All these build systems and package managers that are per language are wrong.

But unfortunately Bazel and Buck have a decade plus of tech debt and baggage from their corporate overlords. Internal buck is actually mostly nice. I don’t know why anyone ever use it externally.

▲

rtpg 3 hours ago | parent [-]

It's not about the package managers not being polyglot. It's about, for example, witnessing that `pip install` installs binaries with absolute paths and then writing a patch _for pip_ that Bazel uses, instead of figuring out how to change upstream pip to make that a configuration bit that Bazel uses.

Bazel uses npm/cargo/pip in most people's usage of these tools! People still use these packages managers, with random patches and tweaks (because the overall ecosystem assumes you're using them). But Bazel often includes random fixups in their own tools.

For example [0] is some patches Bazel does to node to get it to play nicely witH Bazel. In an (IMO) better world Bazel people figure out what they need, and figure out what they can get upstreamed into node to get things working.

Instead we have patches that (if you jump through the history) have been around for 6+ years

[0]: https://github.com/aspect-build/rules_js/tree/main/js/privat...

	▲	forrestthewoods an hour ago \| parent [-]
		> Bazel uses npm/cargo/pip in most people's usage of these tools! Oh interesting. Buck totally replaces cargo / pip. I think the JS story is a little messier. Not sure as I try my best to not touch JS.