First problem: a notion of a package is fuzzy in general. Nix store can contains package data for previous generations or package data that is not in used anymore. So you have to be precise if you consider unused package data to be a package, etc.
From my understanding a closure (that contains many derivations) is the root of all dependencies. For the moment of a clean install the nix store would reflect the same state as the closure. No?
And while I am mainly interested in the dependencies of the current closure it should also be possible to find the ones that are from a previous generation or not used anymore - I would assume.
These two commands raise questions:
nix path-info -r $a_nix_derivation
nix why-depends $package $dependency
While the path info seems to indicatate what gets included in the closure to have a working
nix path-info -r nixpkgs#curl
I am still not sure how to use
why-depends to find all the reasons that caused
curl to be part of the closure.
Usually, a version number of a package can be obtained by reading the Nix store path directly, if it’s not possible, you should have the attribute path and perform the following evaluation attr.version, if there’s a version, you will get an output.
You mean the easiest way to check for the version would be to just use
ls -la /nix/store
I guess that should work for the most part.
But a more standardized way via cli would still be nice. Be it just to have an explicit contract.
aluation can be done via nix-instantiate --eval usually or you favorite way to do so.
Sorry, there you lost the newbie on this side of the thread
I want to see if there is a newer version
This question is hard and non-trivial, Nix doesn’t know what is a version, version are just metadata.
I figured. That said: as long it is a defined field in the metadata a lexical/semver comparision would be enough.
Now, we have various heuristics that should cover almost all cases, we know that versions are usually lexicographically ordered, so it is sufficient to evaluate any latest channels on status.nixos.org 1 for your relevant channel and determine their .version for the package you care about.
If it’s higher, newer versions are available.
That sounds good.
Is this wired in any tooling? No. Should it be? Yes.
Well, for me hearing that is the first step
Unfortunately, we all have finite free time. — if you are interested into this feature, I worked quite on the design to make it available for much more than that, so you can ping me (Matrix/DM/email/IRC/whatever) about it
My Haskell skills are still weak and I am just getting started with nix(os), so I am not sure how much I can contribute.
What I can contribute for sure are expectations of someone learning and give some inputs to the cli UX.
And I would love it to be more. But we’ll have to see how this goes.