Workbrew
workbrew.com
workbrew.com
The entitlement of users calling open source maintainers that try to limit the surface area of support tickets to the systems that provably 95% of users are on “user hostile” is always sad to see.
I reject your name-calling via a strawman, though I support the message.
A better way to describe it might be contributor-hostile than user hostile. In a typical open source project, opening an issue is considered to be a contribution, a pull request is even better. Try doing any of these and be prepared to be harassed.
It is a very toxic open source project. Sadly homebrew cask is irreplaceable.
At the time it felt pointlessly rude but now I realise that the man works for free, and gets to be the king of his own turf. Not all software projects need to be a direct democracy. He doesn't owe us anything.
Your point about project owners having final word is well taken, but in this case possibly also objectively correct.
That person has repeatedly been very curt with people as a matter of policy.
or a different homebrew
Codifying this crap UX, always deploying head to a dev’s machine, setting packages on a dev’s computer and path in some privileged manner that I as a dev using the machine can’t control… it’s terrible.
I should have full control over the development packages on my machine, the environment, etc. fine, put some memory hog scanning crapware on there if it makes IT feel like they are doing something… but don’t touch my path and my dev environment
(Tea, later renamed to pkgx)
- Different folks ran `brew install <foo>` at a different time? They may see different behavior
- I ran `brew install <foo>` after a coworker did? I may not be able to replicate whatever issues they are facing
- Someone new ran `brew install <foo>` on their new laptop? They may have an entirely separate major version of that library with breaking changes.
- Do I know if folks are using vulnerable, old packages? Nope!
- Does production use some database with version X, but homebrew only supports a client for version Y? Eh whatever, just have folks locally use version Y. What could possibly go wrong with using a different version locally vs in production.
I kept our own homebrew tap for a while and pinned versions. That was fine. But then I had to maintain that tap, and there wasn't any easy way I found for checking if the versions we kept in that tap had any vulnerabilities on any registry I could find.
Then I found Github Codespaces / devcontainers, switched everyone to use Linux inside Docker, used linux package managers to install pinned versions of everything we needed (using the same exact packages as we bundle into production), and scan my containers using a container vulnerability scanner nightly.
Instantly, 10+ hours of work per week for me vanished and I can now at least reproduce problems and fix them for everyone when they come up.
I’m already using it for my personal work laptop and it is working well. Also nix allows me to configure host/user level tools such as shells or AWS-sso where docker would not. Building modules allows users to customize there configuration without blocking our tooling team from making changes to configs as Nix will just merge it all together.