4 ms·

As a NixOS user, I like this article a lot. But one thing stood out to me: > It also means that it's impossible to statically know what other packages a given

As a NixOS user, I like this article a lot. But one thing stood out to me: > It also means that it's impossible to statically know what other packages a given package might depend on. Currently, the way this is implemented is essentially grepping a package for /nix/store/ to try to figure out what the dependencies are, which is obviously... not great. I'm not sure what the author is talking about here. He says it's impossible to find static dependencies, but then describes how it's implemented. I'm also not sure why the author thinks this solution is bad? Maybe because it could accidentally pull in more runtime dependencies than you were expecting?

mplanchard 5y ago
There is also a nix store query to find this information. I’m on my phone so I can’t get it right now, but I’ll try to remember to grab it later. You can query all the dependencies of any derivation… this is how I verify the full suite of software that nix-direnv installs for local projects, by querying the store for its cached derivation’s deps.
- valyagolev 5y ago
  i think “statically” means without executing the nix language stuff
  - mplanchard 5y ago
    Oh, I see, thank you for the clarification. I figure it’s just as hard to get a list of transitive packages dependencies without apt or whatever as it is without nix, though. And there’s an argument to be made that a pure function on a derivation can be considered static. But I don’t disagree with any of the general points: especially that nix the language, or more specifically nix in practice as it’s used in nixpgs, is very hard to learn.
deleted 5y ago
[deleted]
tomberek 5y ago
Just like any other package manager, this information can be queried without grep. nix-store --query --references /run/current-system # or with new CLI: nix path-info --recursive /run/current-system This information is managed and tracked for you. And while I understand the desire to have "normal" FHS paths, the hashing and the injection of the hashes (think "tags") is exactly the mechanism that makes dependency tracking possible to do automatically. This is similar to the trick by log aggregation tools that assign each source event a UUID to make it possible to search and find it in all sorts of unexpected places. Otherwise how would you know what "/usr/bin/bash" really means if you came across it in an error log? What version was it at THAT EXACT MOMENT? That hash in the path is the tag that enables all of it to work.
- assbuttbuttass 5y ago
  Right, after the package is built the dependencies are stored with the package metadata like any other distro.

mplanchard 5y ago

There is also a nix store query to find this information. I’m on my phone so I can’t get it right now, but I’ll try to remember to grab it later. You can query all the dependencies of any derivation… this is how I verify the full suite of software that nix-direnv installs for local projects, by querying the store for its cached derivation’s deps.

valyagolev 5y ago
i think “statically” means without executing the nix language stuff
- mplanchard 5y ago
  Oh, I see, thank you for the clarification. I figure it’s just as hard to get a list of transitive packages dependencies without apt or whatever as it is without nix, though. And there’s an argument to be made that a pure function on a derivation can be considered static. But I don’t disagree with any of the general points: especially that nix the language, or more specifically nix in practice as it’s used in nixpgs, is very hard to learn.

deleted 5y ago

[deleted]

tomberek 5y ago

Just like any other package manager, this information can be queried without grep. nix-store --query --references /run/current-system # or with new CLI: nix path-info --recursive /run/current-system This information is managed and tracked for you. And while I understand the desire to have "normal" FHS paths, the hashing and the injection of the hashes (think "tags") is exactly the mechanism that makes dependency tracking possible to do automatically. This is similar to the trick by log aggregation tools that assign each source event a UUID to make it possible to search and find it in all sorts of unexpected places. Otherwise how would you know what "/usr/bin/bash" really means if you came across it in an error log? What version was it at THAT EXACT MOMENT? That hash in the path is the tag that enables all of it to work.

assbuttbuttass 5y ago
Right, after the package is built the dependencies are stored with the package metadata like any other distro.