Hacker News Reader

Comment by puffoflogic | Hacker News Reader

Nix is not capable of becoming a first class dependency manager because it does not manage dependencies. It does not attempt any version or feature resolution. Besides, saying Nix could become a package manager is like saying that C could become a package manager.

View on HN

Nix is an umbrella for a stack of various solutions.

Nixpkgs doesn't do version or feature resolution, but other tools (that are not nixpkgs) can and do.

Under this abuse of terminology, a pocket calculator is capable of becoming a package/dependency manager. Or any other technology which conceivably could be put to work toward the package management problem, but has not yet been adapted to that need. I concede that these statements are "true", but they fail the relevancy test of communication.

Like I said in another comment, the problem is curating the giant database that maps version numbers to commit refs. Once you pass this roadblock, the tools Nix gives you make dependency resolution a quite a bit simpler problem to solve.

The next step is then realizing you actually don't need the useless legacy version numbering scheme at all, and that you wasted that effort for nothing.

Something like this maybe? https://lazamar.co.uk/nix-versions/

I'm not sure what you mean, through, by not needing the actual program versions.

What we actually want is a content-addressable global namespace of source code. (Maybe it could be marketed as "blockchain for software" or something, lol.)

Version numbers are an attempt at content-addressing from the time when software came on floppy disks and CD-ROMs. It sorta made sense given the constraints of that technology.

Nowadays trusting git tags over git revision hashes makes no real sense. (Except that git tags are kinda shorter to type, but who cares.)

Reply on news.ycombinator.com