5 ms·

I appreciate all your hard work and I like Homebrew, but I think updating high-level packages when a descendent dependency is updated is the wrong behavior - at

I appreciate all your hard work and I like Homebrew, but I think updating high-level packages when a descendent dependency is updated is the wrong behavior - at least in this example. If Postgres has an unversioned dependency to PackageX, the only time I might expect Postgres to be updated automatically is if I update PackageX across a major version boundary, risking breaking changes. Even then, I'm not sure I'd want that behavior by default - I'd at least like to be prompted - since often this still won't break anything, or it will likely cause less damage than updating every package with a dependency to PackageX. And if Postgres breaks after I update PackageX I can easily reason about what just happened. The alternative can be incredibly hard to troubleshoot because so many changes have occurred. Overall, Homebrew feels far too aggressive here, and I think the result, for people who have some understanding of Homebrew behavior, is that they're afraid to touch anything.

pxc 5y ago
> If Postgres has an unversioned dependency to PackageX, the only time I might expect Postgres to be updated automatically is if I update PackageX across a major version boundary, risking breaking changes. Homebrew doesn't meaningfully have versioned or unversioned dependencies, because it doesn't incorporate any notion of version into its dependency solver. When you declare a dependency on `python@3.9`, you're not telling `brew` that ‘I need a copy of the package `python` which satisfies the constraint “version is 3.9.x”.’ Homebrew just treats `python@3.9` as the name of a package which is a whole copy of python, and it can exist alongside other, similar packages like `python@3.8` and `python@3.10`. Homebrew only incorporates this kind of `@` syntax for select packages of which maintainers have elected to maintain multiple versions. By my count, there are 81 such packages in homebrew-core, and the following is a complete list of all of those which appear in a `depends_on` declaration: antlr atkmm autoconf cairomm db elasticsearch erlang gcc ghc glibmm go gradle guile hdf5 headers helm isl libfuse llvm lua mbedtls mysql node numpy openexr openjdk openssl pangomm php proj pyqt pyside python qt ruby swig synth tbb vtk wxwidgets So when you look at a Postgres formula in the Homebrew repos and see that it declares an ‘unversioned’ dependency on openldap, for example[1], that does not mean that the formula author has declared ‘any version is fine’, i.e., it does not mean that the dependency is unversioned. It just means that the dependency's version constraints are totally unspecified except implicitly as ‘the only version of that package which is simultaneously present in the glorious monorepo of build recipes’. This is a feature it shares with some source-based package management systems, like Nix and Guix. Those package managers solve this problem by basically vendorizing everything, so installing a new package never upgrades anything else you have installed. Other source-based package management systems, like Portage and Pkgsrc, have extended their model to include some handling of version constraints, but they also sometimes declare dependencies without specifying a version. That seems dubious to me, since in reality there pretty much always are version constraints that ought to be specified there, but maybe those two projects are mature enough that they've hammered out the problematic cases by now. — https://github.com/Homebrew/homebrew-core/blob/master/Formula/postgresql@13.rb https://github.com/Homebrew/homebrew-core/blob/master/Formul...
- 988747 5y ago
  Now I understand better why Homebrew author failed his job interview at Google :)
  - pxc 5y ago
    I find Homebrew really frustrating, and I also sometimes find its popularity relative to more mature or more thoughtfully engineered tools in the same problem domain frustrating. But I think it's unfair and lazy to say that Homebrew's design defects are just there because its author is stupid or something like that. That Homebrew's (massive) success is grounded in virtues other than fundamentals like dependency management doesn't mean that Max Howell has nothing to offer or couldn't be an effective part of a team at Google or anywhere else. I imagine his willingness to just forge ahead with a simple solution when he notices that existing tools aren't serving him well means that he doesn't often get totally stuck, or succumb to paralysis by analysis, for example. He might be great to pair with if you tend to overthink things or get stuck, and I bet he'd be a very helpful critic and contributor when it comes to the user experience of internal CLI tools. There's no need to shit on the guy. He's been very honest and clear about Homebrew's strengths and weaknesses: https://www.quora.com/Whats-the-logic-behind-Google-rejecting-Max-Howell-the-author-of-Homebrew-for-not-being-able-to-invert-a-binary-tree/answer/Max-Howell https://www.quora.com/Whats-the-logic-behind-Google-rejectin...

pxc 5y ago

> If Postgres has an unversioned dependency to PackageX, the only time I might expect Postgres to be updated automatically is if I update PackageX across a major version boundary, risking breaking changes. Homebrew doesn't meaningfully have versioned or unversioned dependencies, because it doesn't incorporate any notion of version into its dependency solver. When you declare a dependency on `python@3.9`, you're not telling `brew` that ‘I need a copy of the package `python` which satisfies the constraint “version is 3.9.x”.’ Homebrew just treats `python@3.9` as the name of a package which is a whole copy of python, and it can exist alongside other, similar packages like `python@3.8` and `python@3.10`. Homebrew only incorporates this kind of `@` syntax for select packages of which maintainers have elected to maintain multiple versions. By my count, there are 81 such packages in homebrew-core, and the following is a complete list of all of those which appear in a `depends_on` declaration: antlr atkmm autoconf cairomm db elasticsearch erlang gcc ghc glibmm go gradle guile hdf5 headers helm isl libfuse llvm lua mbedtls mysql node numpy openexr openjdk openssl pangomm php proj pyqt pyside python qt ruby swig synth tbb vtk wxwidgets So when you look at a Postgres formula in the Homebrew repos and see that it declares an ‘unversioned’ dependency on openldap, for example[1], that does not mean that the formula author has declared ‘any version is fine’, i.e., it does not mean that the dependency is unversioned. It just means that the dependency's version constraints are totally unspecified except implicitly as ‘the only version of that package which is simultaneously present in the glorious monorepo of build recipes’. This is a feature it shares with some source-based package management systems, like Nix and Guix. Those package managers solve this problem by basically vendorizing everything, so installing a new package never upgrades anything else you have installed. Other source-based package management systems, like Portage and Pkgsrc, have extended their model to include some handling of version constraints, but they also sometimes declare dependencies without specifying a version. That seems dubious to me, since in reality there pretty much always are version constraints that ought to be specified there, but maybe those two projects are mature enough that they've hammered out the problematic cases by now. — https://github.com/Homebrew/homebrew-core/blob/master/Formula/postgresql@13.rb https://github.com/Homebrew/homebrew-core/blob/master/Formul...

988747 5y ago
Now I understand better why Homebrew author failed his job interview at Google :)
- pxc 5y ago
  I find Homebrew really frustrating, and I also sometimes find its popularity relative to more mature or more thoughtfully engineered tools in the same problem domain frustrating. But I think it's unfair and lazy to say that Homebrew's design defects are just there because its author is stupid or something like that. That Homebrew's (massive) success is grounded in virtues other than fundamentals like dependency management doesn't mean that Max Howell has nothing to offer or couldn't be an effective part of a team at Google or anywhere else. I imagine his willingness to just forge ahead with a simple solution when he notices that existing tools aren't serving him well means that he doesn't often get totally stuck, or succumb to paralysis by analysis, for example. He might be great to pair with if you tend to overthink things or get stuck, and I bet he'd be a very helpful critic and contributor when it comes to the user experience of internal CLI tools. There's no need to shit on the guy. He's been very honest and clear about Homebrew's strengths and weaknesses: https://www.quora.com/Whats-the-logic-behind-Google-rejecting-Max-Howell-the-author-of-Homebrew-for-not-being-able-to-invert-a-binary-tree/answer/Max-Howell https://www.quora.com/Whats-the-logic-behind-Google-rejectin...