python upgrade doesn't carry over installed modules, but does change current version - which breaks many local python scripts since their dependency modules are now in the old version). I try to install something small and it depends on something like python, which triggers "upgrade the whole universe" loop, which breaks a ton of things (e.g. That said, I did notice recently the same effects as the OP. Homebrew is one of the most useful tools in macos development ecosystem, at least for me. 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. 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. Those package managers solve this problem by basically vendorizing everything, so installing a new package never upgrades anything else you have installed. This is a feature it shares with some source-based package management systems, like Nix and Guix. 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’. So when you look at a Postgres formula in the Homebrew repos and see that it declares an ‘unversioned’ dependency on openldap, for example, 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. 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: When you declare a dependency on 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 as the name of a package which is a whole copy of python, and it can exist alongside other, similar packages like and only incorporates this kind of syntax for select packages of which maintainers have elected to maintain multiple versions. Homebrew doesn't meaningfully have versioned or unversioned dependencies, because it doesn't incorporate any notion of version into its dependency solver. > 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. A reminder that we're a volunteer run project so it's not always as easy as we'd like it to be to get these changes out quickly. Regardless, I appreciate this is a problem and we're still figuring out potential solutions for this problem. The more time left between updating/upgrading, the more likely to have more dependencies updated which requires more dependents to be updated. Either we upgrade _everything_ that depends on that you have installed or we knowingly break some of the things you have installed that depend on We choose the safer option by default. you want to install `virtualenv` that depends on the binary package for `virtualenv` you want requires the newest this upgrades on installation Homebrew does this because the alternative is sometimes breaking things. As mentioned in other comments, you can customise this behaviour with `HOMEBREW_NO_INSTALL_UPGRADE` or `HOMEBREW_NO_AUTO_UPDATE`. Homebrew upgrades dependencies and dependents of those dependencies (which, admittedly, can feel like unrelated) on installation and upgrade. Remember that brew is also implemented on Linux so it makes sense to have this division.Homebrew project leader here: I hope you're able to find a package manager that better fits your needs and I'm sorry that Homebrew is not currently doing so. In a nutshell, brew handles software at the unix level, whereas brew cask extends the functionality of brew into the macOS domain for additional functionality such as handling the location of macOS app bundles. UPDATE: A bit of clarification about brew and brew cask. You should then be able to launch MacVim like you do any other macOS app, including mvim or open -a MacVim from a terminal session. Instead, please consider using brew cask andįor MacVim, you can install with: brew cask install macvim ![]() Spotlight usingĮither aliases or symlinks and Homebrew formulae do not build "proper". ![]() Unfortunately brew linkapps cannot behave nicely with e.g. You may even get the following warning if you brew linkapps: app bundles, you should install them via cask, if available, as using symlinks can cause issues.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |