Devbox for me hasn't clicked as a project-level tool manager, mostly because it doesn't really play nicely with the way our projects are set up causing a lot of shell issues for other team members. Mise has been trouble free on that front though, works perfectly for everyone on the team, and has some nice runner type functionality too (like `just` or `make`). If you've not tried Mise, I recommend giving it a go, it's really nice.
Several upgrades wrecked havoc on my system, a lot of things didn't work as expected, I had to package a lot of stuff; eventually I just bit the bullet and started using homebrew
Personally speaking I might learn it at some point but for now nix's friction/overhead isn’t proportional to the occaisional inconvenience with traditional package managers.
Maybe it would make sense for nix to add a mode that basically aliases that first command to `nix install <package>`.
But yeah, Nix is much more than a homebrew replacement and that has its downsides.
1. Did't actually exist
2. Outdated version
3. Incorrect build
I'll keep the quality of Homebrew packages over the quantity in Nix
- worse ux (nix commands are much more cumbersome and often make no sense compared to `brew install`)
- you have to use some third-party wrappers to make it work on Mac
- features incomplete and outdated packages (and is missing others apparently https://news.ycombinator.com/item?id=44034446)
... but it "does the job better than anything else could".
---
This is the issue I have with the whole nix discourse: it's hailed as this great magical tool. But when pressed for details it's always this: weird commands, configs, working or non-working wrappers etc.
I don't know what you're talking about re: third party wrappers, this is just an option for a slightly easier and perhaps more robust install. And homebrew isn't free of issues at all.
;)
> And homebrew isn't free of issues at all.
No one advertises brew as "the best", "better than everything else" etc.
BTW, looked at Determinate Nix. It's a custom distribution and a custom daemon, and its own fork of documentation
I briefly experimented with nix-darwin, but concluded that it was overkill for my needs. Home Manager also has the benefit of not being Mac-specific (so plenty of questions and examples exist online).
Most importantly, I no longer have to mentally prepare myself when updating Mac OS. If I recall correctly, both MacPorts and Homebrew require the user to re-install all installed packages after a major version update, but this problem doesn't really exist on Nix. It's also nice being able to store flakes in a Git repository and effortlessly rollback changes or replicate a whole development environment across several machines.
I agree that nix-darwin is a bit overkill, I mainly use it for the homebrew integration, but I think so is home-manager, I don't keep user app configs in Nix since they are never exhaustive and more effort than it's worth.
export HOMEBREW_NO_AUTO_UPDATE=1
export HOMEBREW_NO_ANALYTICS=1
export HOMEBREW_NO_EMOJI=1
export HOMEBREW_NO_ENV_HINTS=1
export HOMEBREW_NO_INSTALL_CLEANUP=1Anyway, I don't think this is enough. Or I guess it only works to stop the trigger during install? I have the NO_AUTO_UPDATE set up, and recently needed to update (or upgrade? who knows) a single package and it somehow ended up with Homebrew working for over two hours. I saw it installing python at least two times.
some charity is due here, because this is the culture, and also because for any software tool of sufficient complexity, there is always more to think about than attention to give. But the culture could use more improvement and reflection here.
[1]: https://www.pkgsrc.org/, https://pkgsrc.smartos.org/install-on-macos/
It's written in Rust and quite fast: https://pixi.sh
> What if the package I want is not on github releases?
Easy. Just add the http(s) link to the binary
ie:
kelp add -r https://releases.hashicorp.com/terraform/0.11.13/terraform_0... hashicorp/terraform
righthand•5h ago
steeleduncan•5h ago
geerlingguy•3h ago
There are always tradeoffs with any packaging system, no matter how transparent/simple.
asdff•3h ago
" Unless $HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK is set, brew upgrade or brew reinstall will be run for outdated dependents and dependents with broken linkage, respectively.
However I don't think even these flags are sufficient. I think to really ensure nonbreaking behavior you have to use a brew pin command on each and every formula you have installed on the system.Really annoying defaults considering brew is a developer facing program not a consumer facing program where the tradeoff between security and functionality makes more sense.
This is why I still reach for conda whenever possible. I am at least prompted before 100 things are installed.
acdha•2h ago
It’s been many years since I’ve had a problem caused by Homebrew’s design but if you like keeping things frozen like that, it sounds like you might be a better fit for Nix or working in containers where you aren’t fighting a distribution designed to stay consistently current across the entire system.
asdff•2h ago
It isn't just that things "work together" but in some cases authors change how their tools work between versions and I may have stuff installed that depends on these outdated paradigms. In other words, the stuff I have built is not sure to work together with updated brew packages. I have a few scripts for example where numpy complains how I call some function will no longer merely throw a warning but actually not work at all in future versions. I can either spend my free time to rewrite the script to do it how the numpy authors now want me to do it, or I can just not do that and live on the old numpy and not be any worse for wear.
droelf•1h ago
https://pixi.sh
atmosx•2h ago