Hi, First of all I want to thanks Thomas, for his pull request on the Vim configuration [1]. One of the most interesting part, from my point of view, is to give the Configuration Management aspect of NixOS configuration to manage user environments.
Jan, suggested a similar idea except that the module lies in the derivation files of the packages. Even if I do not like the approach of storing the modules inside the derivation, I think this is the rough idea we should be aim at, at least at the package level. Jan also suggested to have activations scripts, which is an idea coming from NixOS. Having such a thing would be very convenient at the user level, but leads to multiple questions to know what does it maps to at user profile. (as I am waiting to get feedback / reviews for the Nix's secret branch [2]) I started to work on a system (NixUP) which would be identical and compatible with NixOS, the idea would be to have another tool for managing user profiles, which would be similar to what nixos-rebuild do, and nixos-option should almost the same way. By compatible, I want us to be able to have modules which are targeting both NixOS options and NixUP options. Also, ideally NixUP modules should be valid sub-modules for the "users.extraUsers" option, such as anything which can be handled at the user level can also be handled at the system level. (such as openssh.authorizedKeys.keys) Among the thing that I am trying to get right at the moment, is what does it means to activate a user profile? Should the activation of a user profile be done only when you switch to a new profile (changing $HOME/.zshrc), or should it be something done only once we are logged in (ssh-agent), or should it be something which is done every time we start a terminal? I think that all these use cases deserved to be considered as valid activations, and then the question is how do we manage them properly. So far, on all my computers, I have been managing my user configuration with a private git repository hosted on a server. I think this is time to change and to update it to use a new model based on NixOS module system. One of the thing that I want everybody to keep in mind, is that doing such system implies that we should not be relying on the operating system. We should not assume that a user can use systemd processes, and this implies that we will have to support multiple backends. Maybe, later, we could be writing some default abstraction based on the operation system on which the user environment is running (host.system = "debian"), or even infer it in a similar way as hardware-config.nix. Also note, that NixUp should NOT be considered as a replacement of nix-env or Nixpkgs. Managing a configuration of one user does not replace the management of a user environment. nix-env provides some convenient imperative management such as one-click-install, which are not working with the module system (so far). [1] https://github.com/NixOS/nixpkgs/pull/4493 [2] https://github.com/NixOS/nix/pull/329 -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
