3 ms·

It evaluates the build plan for everything we have, and then searches the things that were evaluated. The new unstable CLI has an evaluation cache at least. W

It evaluates the build plan for everything we have, and then searches the things that were evaluated. The new unstable CLI has an evaluation cache at least. What most people do today is look for keys in the object and just evaluate what they need. (The Nix language is lazily evaluated so you can explore like this pretty well out of the box in the repl.) Or, they just grep Nixpkgs :D. ------- All of this, problems and solutions alike, is a weird situation to be in. I still stand by "just get rid of nix-env -i", but I want there to be better solutions too. Nixpkgs seems overly complex, and is in some ways, but the fact its trying to herd a gazillion upstream packages that don't meaningfully coordinate makes this harder to fix than it should be.

Fnoord 6y ago
On a machine which isn't idle: $ time nix-env -qa > nixdb.txt ________________________________________________________ Executed in 470.40 secs fish external usr time 25.11 secs 35.00 millis 25.07 secs sys time 10.05 secs 27.00 millis 10.02 secs $ ls -s nixdb.txt 736 nixdb.txt A plain-text database of less than 1 MB, which took less than 10 minutes to generate. It is going to remain useful for my use-case ("see if a package is available in Nixpkgs without going to packages.nixos.org"). Now I can just use grep or rg. Sure, Nix or Nixpkgs could have such (or a better) database native, but I don't see problem with above. Maybe someone cares to explain?