search

MatrixAI / nixos-platforms

NixOS System Configuration for Platforms used by Matrix AI
MIT License
0 stars 0 forks source link

Pinning in `configuration.nix` similar to `default.nix` #9

Closed CMCDragonkai closed 6 years ago

CMCDragonkai commented 6 years ago

Should nixpkgs be pinned in configuration.nix?

We left it outside, so it's an open expression, to be closed on the presence of wherever <nixpkgs> points to which is pointing to /nix/nixpkgs.

This is similar to the default.nix using pkgs pointing ./pkgs.nix. Rather than using the OS <nixpkgs>.

There is some flexibility, but the problem comes when managing multiple configs compatible with different nixpkgs versions in a single project. This means this repository handles "multiple" NixOS systems, which means the pinning must be granular and explicit to each system.

But at the same time, we may want to allow them to be mutable, in which case we want to have a git repository that we can tightly control, rather than pointing at some place that will be imported into /nix/store.

We could do something similar with pkgs.nix, thus pointing at a directory. Or rely on submodule. This seems like a classic difference between development requirements and deployment requirements.

CMCDragonkai commented 6 years ago

Certainly the hash of the nixpkgs must be made available to the configuration.nix. It's also important that user profile config.nix relies on the same OS nixpkgs. Alternatively the user profile configuration can evolve separately from the OS configuration.nix. Generally this is the correct idea. Because you may need things inside the user profile depending on things that no longer is part of the OS configuration. But this does add a lot of redundancy if the 2 pins fall out of sync.

So what should happen is that both are pinned, but they should be brought to synchronisation as often as possible.

Remember that it's quite common for the user profile configuration to be far more larger than the OS configuration.

Furthermore the user profile configuration needs to be broken up so that things like work dependencies aren't be installed with non-work dependencies. This can be done by presenting multiple choices in the config.nix. Right now it's all part of env-all.

The other issue is that we currently use a Git repository to act as the pinned nixpkgs. But this may not be the right idea as it means keeping a copy of the nix expressions all the time. The alternative is encoding the hash as just a pkgs.nix. This can be quite important if you have multiple projects all with their own pins.

What would be nice, is the ability to easily transition between different hash points and development where you can tweak the package set. Actually this is possible by having a nixpkgs project, and for nix-env -f ~/Projects/nixpkgs. But what about the OS? You could always point to a /nix/nixpkgs which would be a custom repository if you work on NixOS itself.

CMCDragonkai commented 6 years ago

This is now done in https://gitlab.com/MatrixAI/Platforms

CMCDragonkai commented 6 years ago

The main issue is that you need to use a filesystem path for NIX_PATH that doesn't change (as in the path doesn't change when performing a rebuild). Otherwise shells will need to be restarted.