you can search packages relatively efficiently assuming you are willing to use experimental features:
If you do something like nix.registry.nixos.flake = inputs.nixpkgs in your config, then you have a static reference of the nixpkgs revision used to build your system.
By then calling nix search nixos $package, the first run will popullate Nix’s evaluation cache. Subsequent runs will then be cached and much faster. You can also use this registry entry to enter a nix repl with :lf nixos to quickly tab complete through packages. I have a convenient alias for this in my config.
Your points are valid though, and hopefully we can continue to improve on these fronts.
Thanks for reading my post!
Yes I knew about the search in the experimental features I was already using it, but as many people are not comfortable with using experimental stuff I thought it was important to mention
The stable CLI does also have a search functionality, but less polished: nix-env -qaP == nix-env --query --available --attr-path
so I may go back to a more traditional
In this case, you’ll be better off to start using GitHub - nix-community/home-manager: Manage a user environment using Nix [maintainer=@rycee]
Same idea, exactly the same principles, but instead of targeting / & /boot, it targets ~ hooked up in your shell’s rc file instead of the bootloader.
The nice thing: you can make gradual use of nix, i.e. files under home-manager-management and manually curated files can coexist.
And last, but not least: likely, most of the CLI tools, you want to take them with you in your user environment, anyways. Not bound to your system and metal.
At least it’s an easy and gradual on-ramp. And it’s like securing a hefty discount on coming back later.