4 ms·

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.

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.

tazjin 4y ago
[flagged]
- pxc 4y ago
  Pretend I asked the nice version of this, for the benefit of other readers? I do think a Nix-like tool to be used for writing/replacing package managers for new programming languages would benefit from some dependency resolving functionality, instead of just saying 'shove it in a monorepo or pin via VCS refs instead of semver'. Is that not necessary?
  - otabdeveloper4 4y ago
    Nix is capable of that, but you need a database mapping versions to VCS refs. Nixpkgs doesn't go down that road because it would be unwieldy at their scale, but more specialized nix-based tools do.
    - pxc 4y ago
      (I actually think Nixpkgs could and should go down this road, with a couple of caveats, for immense benefit. But I'm curious about what tazjin thinks here.)
    - haradion 4y ago
      At least for (unlocked) flake sources, you could probably use a branch naming convention instead of a separate database, although that requires your repo to be set up a specific way.
otabdeveloper4 4y ago
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.
- puffoflogic 4y ago
  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.
  - otabdeveloper4 4y ago
    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.
    - tripdout 4y ago
      Something like this maybe? https://lazamar.co.uk/nix-versions/ https://lazamar.co.uk/nix-versions/ I'm not sure what you mean, through, by not needing the actual program versions.
      - otabdeveloper4 4y ago
        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.)

tazjin 4y ago

[flagged]

pxc 4y ago
Pretend I asked the nice version of this, for the benefit of other readers? I do think a Nix-like tool to be used for writing/replacing package managers for new programming languages would benefit from some dependency resolving functionality, instead of just saying 'shove it in a monorepo or pin via VCS refs instead of semver'. Is that not necessary?
- otabdeveloper4 4y ago
  Nix is capable of that, but you need a database mapping versions to VCS refs. Nixpkgs doesn't go down that road because it would be unwieldy at their scale, but more specialized nix-based tools do.
  - pxc 4y ago
    (I actually think Nixpkgs could and should go down this road, with a couple of caveats, for immense benefit. But I'm curious about what tazjin thinks here.)
  - haradion 4y ago
    At least for (unlocked) flake sources, you could probably use a branch naming convention instead of a separate database, although that requires your repo to be set up a specific way.

otabdeveloper4 4y ago

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.

puffoflogic 4y ago
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.
- otabdeveloper4 4y ago
  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.
  - tripdout 4y ago
    Something like this maybe? https://lazamar.co.uk/nix-versions/ https://lazamar.co.uk/nix-versions/ I'm not sure what you mean, through, by not needing the actual program versions.
    - otabdeveloper4 4y ago
      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.)