Pocnix: a proof-of-concept Nix CLI

Since there was a dicussion about the usage of all the CLI tools here on Discourse, I figured it would be cool to have a rough CLI tool that incorporated some of those ideas:

It is a tool that supports the following commands:

pocnix local install hello
pocnix user install hello
sudo pocnix system install hello

It uses a pkgs.json file to define which packages should be installed in an environment. This file needs to be referenced from default.nix, home.nix and/or configuration.nix.

To help set up a correct environment, you can use the following commands to set up the Nix files correctly:

pocnix local init
pocnix user init
pocnix system init

It will create Nix files if they do not yet exist and otherwise give an example how these files should look like.

It is very rough. Made it this evening. The intention is not to create a good CLI alternative to Nix, but to spark some discussion on what the Nix CLI could be doing.

The current suite of CLI tools are quite varying in their usage and there are different workflows involved to do seemingly similar things. Sometimes editing files and switching, sometimes ad-hoc installations using nix-env. In addition, quite a few NixOS users have switched from using nix-env to using home-manager or similar solutions.
Lastly, nixpkgs pinning should (imo) be a default for most usages of Nix, but this is often still a bit of a hassle. nix-channel is convenient, but its usage goes against the philosophy of Nix (reproducability).

The user interface is especially important when showing off Nix to (potential) new users. It is hard to sell, as its usage is far from convenient compared to language-specific package managers with which most people are quite familiar. Those tools nowadays all have pinning by default. Installing packages is easy, while still easy to share with others over version control.

Anyway, let me know what’s on your mind in this regard!

5 Likes

I also want to throw in nix-flakes.md · GitHub which addresses some stuff mentioned here.

3 Likes

I can share just observed experience. When I tried told one colleague to just use Nix in a Linux VM already to install stuff with complicated dependencies, this is what I ended up writing to make general Nix usage acceptable for him:

(N=1 experiment, of course)

Note that: 1) removal and installation are both by attribute-name; 2) installing something does not necessarily update the other packages; that’s intended.

1 Like

This threads reminds a bit of AUR helpers: AUR helpers - ArchWiki

Thanks a lot for that gist! It seems that one was quite hidden, because I have not found any issue or PR with further discussions referring to that gist. It contains a lot of thoughts that are very relevant. @edolstra would it be a good idea to create an issue/RFC for that gist?

That’s also a very interesting approach: taking the output of nix-build, building a environment from those outputs and replacing the profile. The script is very straightforward and easy to determine what it is doing. It’s nice that all packages are basically ‘locked’ automatically. It seems very intuitive to do this in a home directory and installing packages ad-hoc. It does need a different approach when the environment needs to be reproducible (for project-specific packages).

Still though I think nix-do does exactly what most people would think a package manager would do. This should definitively be part of any nix-env UX discussions.