<provocative=“on”>“A comprehensive package manager for $LANG” is an oxymoron. I don’t know how one could witness the glory of Nix, build their first cross-ecosystem virtualenv and then still root their thoughts on some fictitious inherent need for package management segregation. ‘Shell ecosystem’ needs a separate package manager about as much as ‘all packages ending with a a hard consonant’ do.
It feels like this comment means to disagree, but this is precisely the point:
By comprehensive package manager for shell, I mean roughly: a package manager that can supply Shell scripts and all of the dependencies (other Shell libraries, executables, and so on) needed to just run them. It should not fall prey to the dependency-management problems I mentioned in part 1: it should automatically install the script’s dependencies without polluting the user/system environment (and causing related dependency conflicts).
Not only is such a solution tractable, but it’s already cutting its teeth. In early 2020 I started writing resholve (which helps discover external dependencies and resolve them to absolute paths) to enable Nix/nixpkgs to meet this need. resholve landed in nixpkgs in early 2021 and after adding some important features over the course of the year it is now able to handle a significant fraction of Shell packages.
Someone else in another forum also read this as proposing something other than a general package manager.
I’m curious if you think changing this sentence:
By comprehensive package manager for shell , I mean roughly: a general-purpose package manager that can supply Shell scripts and all of the dependencies (other Shell libraries, executables, and so on) needed to just run them.
is enough to head off this reading? (Or perhaps it is rooted in something else?)
I’m afraid it’s rooted squarely in “comprehensive package manager for shell” and nothing short of “comprehensive package manager for my (specific task of deploying shellscripts or equivalent)” will work out, sorry. “By puppies I mean kitties” doesn’t work outside of math and logic classes.
Not sure how this applies. The post’s paragon of the comprehensive package manager for Shell is nix+nixpkgs.
And so is the one for Python + Node or Ruby + C or typesetting a poster with pandoc + xelatex or building a distro. But stressing the shell part too much is gonna you those misreadings.
I agree that there’s a risk in stressing the Shell part, but this is the part that changed–I think it’s a risk I have to take.
At the end of 2020, nix+nixpkgs was still in the category of general-purpose package managers that could not package Shell without falling prey to the dependency-management problems mentioned.
During 2021, this changed.
There is now a general-purpose package manager that can ~comprehensively package Shell, and it’s nix+nixpkgs.