Brew got one thing right that no Linux package manager seems to emulate: it doesn't require root for normal operations and even goes so far as to error out if running as root (https://docs.brew.sh/FAQ#why-does-homebrew-say-sudo-is-bad).
Brew is so full of Linux/OSS/GNU anti-patterns that I can't wrap my head how did it ever managed to receive so much adoption. I guess macOS people are way more ignorant about things that made Linux/OSS what it is.
In multi-user mode, Nix uses dedicated build users to write to the store. There is also single-user mode, but that also doesn't require a world-writable store.
There is also conda/mamba/pixi/etc. (anything in the conda-forge ecosystem) that can be used without root. Then there are Guix and nix, which (mostly) require to be set up by someone with root privileges, but which then allow unprivileged users to install packages for themselves. I think I have even used emerge rootless-ly at some point a few years ago.
Looking at internal/commands/install.go, it only installs new packages, but doesn't uninstall removed ones. That's the biggest benefit of Brew bundle gone.
apk uses a similar approach by default, and I think it's a wonderful way for a package manager to operate.
Basically, /etc/apk/world keeps a list of explicitly installed packages.
When you manually install a package, it's added to this list, when you manually remove a package, it's removed from the list.
Installation and upgrading (and "fixing) merely ensures that those packages and their dependencies are installed, no more, no less. This also automatically cleans up stale, unused dependencies.
It's a lovely way to get deterministic results. You can just back-up that world file, or copy it to another machine and get the exact same installation.
Big fan! Was like magic at first but now I have a big bunch of Aptfiles to deal with instead... Currently working on solving that with the next-generation tool apt-bundle-bunch, which has a simple declarative format to manage your apt-bundle projects in an Aptbundlefile. It's already great for agents and Im working with Claude on a curl|sh install for the v1.
> Big fan! Was like magic at first but now I have a big bunch of Aptfiles to deal with instead... Currently working on solving that with the next-generation tool apt-bundle-bunch, which has a simple declarative format to manage your apt-bundle projects in an Aptbundlefile. It's already great for agents and Im working with Claude on a curl|sh install for the v1.
Good luck share the progress and let us know how it goes. Is it similar to nix? but from what I can feel, is intending to be simpler?
One key insight is that bundles are really sets of packages and that what we're doing when we bundle things is really just set join operations. Imagine the possibilities if we implement arbitrary set operations. So a bunch is defined as a set of bundles (which can themselves be down to a single package of course) and the declarations in the Aptbundlefile translates under the hood to references and set operations. This is not only declarative, it's also purely functional. Still working on if arbitrary set operations should be accessible by DSL in Aptbundlefile or if that should be left to tools building on top of intermediary API. So yeah, parallels to Nix for sure but it's still apt packages, not building the world from source.
The ppa directive hints that this is intended for Ubuntu because otherwise installing PPAs is a great way to break a non Ubuntu distro.
The deb directive uses the old and soon to be deprecated .list file extension. DEB822 format is the replacement.
The key directive adds the key as globally trusted for all repos instead of locking it to a specific repo as recommended by Debian. I think this is required under the new DEB822 repo format.
What shell scripts would help here? I love me some shell scripting but always reached for debfoster before falling in love with Pac-Man's `-Qe` and `-Qt`
Edit: oh this aptfile doesn't do the one thing I actually use brew bundle for: cleaning up the mess of leftover packages
Brew got one thing right that no Linux package manager seems to emulate: it doesn't require root for normal operations and even goes so far as to error out if running as root (https://docs.brew.sh/FAQ#why-does-homebrew-say-sudo-is-bad).
"let's allow any user process to modify my binaries" is not something to be proud of...
Brew is so full of Linux/OSS/GNU anti-patterns that I can't wrap my head how did it ever managed to receive so much adoption. I guess macOS people are way more ignorant about things that made Linux/OSS what it is.
Can you give some examples?
It needs world-writtable /opt/homebrew, so I guess a Linux equivalent would be Nix (which IIUC requires writable /nix).
For something that only uses your home folder, I recommend checking out mise https://mise.jdx.dev/
In multi-user mode, Nix uses dedicated build users to write to the store. There is also single-user mode, but that also doesn't require a world-writable store.
Or just homebrew on Linux?
Brew _is_ a linux package manager.
There is also conda/mamba/pixi/etc. (anything in the conda-forge ecosystem) that can be used without root. Then there are Guix and nix, which (mostly) require to be set up by someone with root privileges, but which then allow unprivileged users to install packages for themselves. I think I have even used emerge rootless-ly at some point a few years ago.
Looking at internal/commands/install.go, it only installs new packages, but doesn't uninstall removed ones. That's the biggest benefit of Brew bundle gone.
BTW how much of it is vibe coded?
apk uses a similar approach by default, and I think it's a wonderful way for a package manager to operate.
Basically, /etc/apk/world keeps a list of explicitly installed packages.
When you manually install a package, it's added to this list, when you manually remove a package, it's removed from the list.
Installation and upgrading (and "fixing) merely ensures that those packages and their dependencies are installed, no more, no less. This also automatically cleans up stale, unused dependencies.
It's a lovely way to get deterministic results. You can just back-up that world file, or copy it to another machine and get the exact same installation.
apt-mark manual has allowed the same functionality in apt since forever and probably inspired apk's copy of it :)
aconfmgr[https://github.com/CyberShadow/aconfmgr] is a kinda similar project for pacman-based distributions.
The difference is that it strives to track all non-user files, (not just packages, and especially /etc), but you can adopt it partially.
So, this is better than `dpkg --get-selections/--set-selections`? Oh, because it's partial?
Big fan! Was like magic at first but now I have a big bunch of Aptfiles to deal with instead... Currently working on solving that with the next-generation tool apt-bundle-bunch, which has a simple declarative format to manage your apt-bundle projects in an Aptbundlefile. It's already great for agents and Im working with Claude on a curl|sh install for the v1.
> Big fan! Was like magic at first but now I have a big bunch of Aptfiles to deal with instead... Currently working on solving that with the next-generation tool apt-bundle-bunch, which has a simple declarative format to manage your apt-bundle projects in an Aptbundlefile. It's already great for agents and Im working with Claude on a curl|sh install for the v1.
Good luck share the progress and let us know how it goes. Is it similar to nix? but from what I can feel, is intending to be simpler?
One key insight is that bundles are really sets of packages and that what we're doing when we bundle things is really just set join operations. Imagine the possibilities if we implement arbitrary set operations. So a bunch is defined as a set of bundles (which can themselves be down to a single package of course) and the declarations in the Aptbundlefile translates under the hood to references and set operations. This is not only declarative, it's also purely functional. Still working on if arbitrary set operations should be accessible by DSL in Aptbundlefile or if that should be left to tools building on top of intermediary API. So yeah, parallels to Nix for sure but it's still apt packages, not building the world from source.
I hate the Aptfile format after looking at it.
The ppa directive hints that this is intended for Ubuntu because otherwise installing PPAs is a great way to break a non Ubuntu distro.
The deb directive uses the old and soon to be deprecated .list file extension. DEB822 format is the replacement.
The key directive adds the key as globally trusted for all repos instead of locking it to a specific repo as recommended by Debian. I think this is required under the new DEB822 repo format.
man the things people come up with to avoid writing bash scripts
Given your username, do you have the same reaction to bundler?
What shell scripts would help here? I love me some shell scripting but always reached for debfoster before falling in love with Pac-Man's `-Qe` and `-Qt`
Edit: oh this aptfile doesn't do the one thing I actually use brew bundle for: cleaning up the mess of leftover packages
I've been loving the Alpine Package Keeper, especially easily maintaining desired packaging state in /etc/apk/world
https://wiki.alpinelinux.org/wiki/Alpine_Package_Keeper#Worl...
What is this tool solving that I can't do with apt+bash already?
Probably nothing other than the fact that you don't have to maintain it and have less worries about portability, like most command line utilities.
Still, can you share your script?
I wish I could upvote this more than once.
I am having a hard time seeing that the install config isn't just basically bash with some aliases...but I still haven't had my second cup of coffee.
This appears to be a Show HN.
Put in my mise.toml :)