In the case of Watchman, I have to assume that internal use is the most supported use case, and uniformity of deployment is desirable across the fleet there, and so, configurability wasn't as big of a concern?
That makes sense. The weird part to me is that Homebrew would limit their approach and eliminate an entire class of use cases to accommodate programs that work this way. There has to be more to it.
I don't think that's accurate—homebrew specifically says that it only uses the .linuxbrew directory when a formula contains a hardcoded path (which it scans for), and only if you choose not to install it from source.
So, based on the responses from the maintainers, for the .linuxbrew directory to be used, you have to satisfy 2 conditions:
1. you have to be installing one of the ~10% of formula that isn't trivially relocatable.
2. you have to be using a precompiled binary (which it seems like homebrew is smart enough to not do if condition #1 fails and you're not using sudo)
My short experience with Watchman (a few years ago) indicates this. It’s pretty clearly only technically open-source, without much regard at all paid to third parties actually using it.
I’ve had a few build pipelines break over the years because of a watchman dependency. IIRC it was usually an issue with an npm library depending on watchman but downloading a binary that was incompatible with the architecture or implemented the wrong syscalls for the operating system.
