nixuser: declarative user environments #9250

ts468 · Aug 14, 2015

What is Nix User Profile (NixUP)? NixUP is a declarative configuration for the user environment. It is an equivalent to the NixOS configuration method that is based around 'nixos-rebuild' and '/etc/nixos/configuration.nix'. NixUP provides a module system for configuring the user environment and is intended as a replacement for the imperative 'nix-env' commands. NixUP allows to, e.g., install packages, manage user defined services and to manage resources.

NixUP consists of a new program, called 'nixup' and a declarative configuration rooted at '$XDG_CONFIG_HOME/nixup/profile.nix' (e.g. ~/.config/nixup/profile.nix). Basically, the workflow for managing the NixUP user profile is the same as how the NixOS system configuration is being managed. The 'profile.nix' is edited by the user, and then turned into an active environment through 'nixup'.

The important commands for using 'nixup' are:

nixup build
-- Builds a user profile. By default the profile is defined
in $XDG_CONFIG_HOME/nixup/profile.nix.

nixup login
-- Builds a user profile that will be activated on the next login.
That is similar to nixos-rebuild boot.

nixup switch
-- Builds a user profile and immediately switches to it.

nixup edit
-- Opens an editor with the current configuration.

NixUP also brings an small program that helps to install and to remove software packages. If 'config.imperativeNix.enable=true' is set in the 'profile.nix' configuration, then a program 'nix-package' becomes available that manages a list of packages to be installed into the user environment. By default the list is maintained at '$XDG_CONFIG_HOME/nixup/packages.nix', from where the list is read by a module of the NixUP system.

The commands for using 'nix-package' are:

nix-package install hello

nix-package remove hello

Note that the packages are not pinned at a particular version but are linked to the currently active nixpkgs channel. A way to pin a package will be provided later.

Besides managing software packages, NixUP also provides a way to manage user controlled services. NixUP allows to define services for 'systemd --user', similarly to how NixOS allows to define services for 'systemd'. That means that the feature of managing services within NixUP is bound very tightly to 'systemd', and will not be available on other platforms like OSX or Windows.

The last interesting feature of NixUP is that is allows to manage resources. That means, it allows to define files in 'profile.nix' that are then linked into the $HOME directory of a user, or into any sub-directory of $HOME. The necessary sub-directories and links are created as needed, and automatically removed when the 'profile.nix' changes. Automatically created sub-directories are removed if they are empty after all links have been removed. So NixUP has a built-in way for managing, e.g., dot-files.

Could I get some feedback and ideas about how to name the configuration tree for nixuser, please?

@nbp Can it be merged with #4594?

ts468 · Aug 14, 2015

Could I get some feedback and ideas about how to name the configuration tree for nixuser, please?

@nbp Can it be merged with #4594?

Great work! 👍

jgeerds · Aug 14, 2015

Great work! 👍

Why do we need this when we have .nixpkgs/config.nix where we can write our environments?
I think that's an redundant work and can confuse people.

jagajaga · Aug 14, 2015

Why do we need this when we have .nixpkgs/config.nix where we can write our environments?
I think that's an redundant work and can confuse people.

Just to preempt a discussion about WHY we need it, don't be tricked by the simplicity of the settings that are available so far. Nixuser is intended as a central place where user environment related configuration options can be collected. So it goes beyond an individually created .nixpkgs/config.nix.

ts468 · Aug 14, 2015

Just to preempt a discussion about WHY we need it, don't be tricked by the simplicity of the settings that are available so far. Nixuser is intended as a central place where user environment related configuration options can be collected. So it goes beyond an individually created .nixpkgs/config.nix.

That's an extra thing. I really don't see anything we don't have now that you want there.
The only thing we miss --- managing user dotfiles.

jagajaga · Aug 14, 2015

That's an extra thing. I really don't see anything we don't have now that you want there.
The only thing we miss --- managing user dotfiles.

For instance, per-user declarative systemd services (with e.g. the same start/stop and restart-if-config-changed logic that nixos-rebuild has) is something that needs nixuser-rebuild and can't be done with .nixpkgs/config.nix alone.

dezgeg · Aug 14, 2015

For instance, per-user declarative systemd services (with e.g. the same start/stop and restart-if-config-changed logic that nixos-rebuild has) is something that needs nixuser-rebuild and can't be done with .nixpkgs/config.nix alone.

@jagajaga maybe you want to write a nixuser module to manage dot-files?---It would be great contribution!

ts468 · Aug 14, 2015

@jagajaga maybe you want to write a nixuser module to manage dot-files?---It would be great contribution!

The Obligatory Bikeshed: The filename configuration.nix is sort-of already taken, in particular man configuration.nix already brings up the NixOS manual. Maybe something like ~/.nixuser/user-config.nix?

dezgeg · Aug 14, 2015

The Obligatory Bikeshed: The filename configuration.nix is sort-of already taken, in particular man configuration.nix already brings up the NixOS manual. Maybe something like ~/.nixuser/user-config.nix?

Could I get some feedback and ideas about how to name the configuration tree for nixuser, please?

I will look deeply into it later.

@nbp Can it be merged with #4594?

I think so.

The problem I wanted to avoid is that we have to edit a configuration file to add packages.

I think nix-env is a convenient tool for installing new packages. But nixuser-rebuild only provide a NixOS like approach, which is not a user friendly CLI for installing/uninstalling packages.

nbp · Aug 14, 2015

Could I get some feedback and ideas about how to name the configuration tree for nixuser, please?

I will look deeply into it later.

@nbp Can it be merged with #4594?

I think so.

The problem I wanted to avoid is that we have to edit a configuration file to add packages.

I think nix-env is a convenient tool for installing new packages. But nixuser-rebuild only provide a NixOS like approach, which is not a user friendly CLI for installing/uninstalling packages.

@dezgeg Thanks for pointing that conflict out! I hoped we could mirror nixos-rebuild as much as possible and that motivated ~/.nixuser/configure.nix. Also, what do you think about nixup (nix user profile) instead of nixuser? It's used in #4594 and would also be a good choice. I'm just trying to collect opinions :)

@nbp Thanks for going to have a look! Let me know once I can go ahead with merging our two PRs. However, having an explicit configuration file where all installed packages have to be listed is exactly what I want to achieve! To me it is one of the most important features of NixOS that the whole configuration is in one file or place, and if possible I would like to have (exactly) the same for nixuser/nixup. And, text editors are still a very good CLI based configuration tool, i think ;) But of course you're right that a nice GUI would be highly appreciated! Maybe we can generate one semi-automatically from the module definitions, I think @matejc has been working on something like that.

ts468 · Aug 14, 2015

@dezgeg Thanks for pointing that conflict out! I hoped we could mirror nixos-rebuild as much as possible and that motivated ~/.nixuser/configure.nix. Also, what do you think about nixup (nix user profile) instead of nixuser? It's used in #4594 and would also be a good choice. I'm just trying to collect opinions :)

@nbp Thanks for going to have a look! Let me know once I can go ahead with merging our two PRs. However, having an explicit configuration file where all installed packages have to be listed is exactly what I want to achieve! To me it is one of the most important features of NixOS that the whole configuration is in one file or place, and if possible I would like to have (exactly) the same for nixuser/nixup. And, text editors are still a very good CLI based configuration tool, i think ;) But of course you're right that a nice GUI would be highly appreciated! Maybe we can generate one semi-automatically from the module definitions, I think @matejc has been working on something like that.

cc @edolstra

jagajaga · Aug 14, 2015

cc @edolstra

Does this depend on NixOS, or could it work on other Nix platforms?

copumpkin · Aug 15, 2015

Does this depend on NixOS, or could it work on other Nix platforms?

@copumpkin I think it should work on other platforms as well, but I haven't tested it.

ts468 · Aug 15, 2015

@copumpkin I think it should work on other platforms as well, but I haven't tested it.

@nbp Can it be merged with #4594?

Apart from the options for managing the nixpkgs configuration, and the user packages / path, it seems that our implementations can safely be merged, except for renaming integration.

Honestly, I prefer the approach taken in NixOS, which is to have a central list of build targets stored in user.build, and then the top-level script nixuser-rebuild should pull any installable targets from this attribute set.

The interesting part of NixUP is the implementation of the activation script and the resources files, which ideally should be executed by the shell at the start-up of the shell. This activation script serves as an init-system for the user home directory.

I am not convinced by the -rebuild in the nixuser-rebuild name, as I consider this to be an implementation detail.

However, having an explicit configuration file where all installed packages have to be listed is exactly what I want to achieve! To me it is one of the most important features of NixOS that the whole configuration is in one file or place, and if possible I would like to have (exactly) the same for nixuser/nixup. And, text editors are still a very good CLI based configuration tool, i think ;) But of course you're right that a nice GUI would be highly appreciated! Maybe we can generate one semi-automatically from the module definitions, I think @matejc has been working on something like that.

I agree, being able to define packages declaratively is nice, but the imperative style provided by nix-env is convenient.

What I was thinking about was to let the CLI tool generate the modules which are adding the packages in the environment.

nbp · Aug 15, 2015

@nbp Can it be merged with #4594?

Apart from the options for managing the nixpkgs configuration, and the user packages / path, it seems that our implementations can safely be merged, except for renaming integration.

Honestly, I prefer the approach taken in NixOS, which is to have a central list of build targets stored in user.build, and then the top-level script nixuser-rebuild should pull any installable targets from this attribute set.

The interesting part of NixUP is the implementation of the activation script and the resources files, which ideally should be executed by the shell at the start-up of the shell. This activation script serves as an init-system for the user home directory.

I am not convinced by the -rebuild in the nixuser-rebuild name, as I consider this to be an implementation detail.

However, having an explicit configuration file where all installed packages have to be listed is exactly what I want to achieve! To me it is one of the most important features of NixOS that the whole configuration is in one file or place, and if possible I would like to have (exactly) the same for nixuser/nixup. And, text editors are still a very good CLI based configuration tool, i think ;) But of course you're right that a nice GUI would be highly appreciated! Maybe we can generate one semi-automatically from the module definitions, I think @matejc has been working on something like that.

I agree, being able to define packages declaratively is nice, but the imperative style provided by nix-env is convenient.

What I was thinking about was to let the CLI tool generate the modules which are adding the packages in the environment.

@nbp Thanks for your feedback, I'll take it into account! I already had a closer look at how to merge the two implementations, and I have to say, I just started to fully understand and appreciate all the nice details that you put into NixUP! I think you've done an amazing job! Thank you very much for putting it together, it would be a shame if your work wouldn't make it upstream. I just hope I don't break too much while merging the two PRs.

I was reading up on the mailing list again about your introduction of your PR, especially the question when to activate a new user environment. I think it should be possible to have different options like nixup switch or nixup login or nixup shell to distinguish between an immediate activation, an activation with a new login or an activation just for the current shell. What do you think?

I like the idea about your CLI very much. What about a hidden configuration file outside of the nixup/nixuser configuration tree that is only managed by an CLI, and then sourced appropriately? I could imagine to have, e.g., ~/.nixup/profile/managed/{permanent,temporary} where packages are added or removed. The difference could be that the temporary packages are only available until the next rebuild of the declarative environment, whereas permanent packages are kept until they are removed. Could that work?

ts468 · Aug 15, 2015

@nbp Thanks for your feedback, I'll take it into account! I already had a closer look at how to merge the two implementations, and I have to say, I just started to fully understand and appreciate all the nice details that you put into NixUP! I think you've done an amazing job! Thank you very much for putting it together, it would be a shame if your work wouldn't make it upstream. I just hope I don't break too much while merging the two PRs.

I was reading up on the mailing list again about your introduction of your PR, especially the question when to activate a new user environment. I think it should be possible to have different options like nixup switch or nixup login or nixup shell to distinguish between an immediate activation, an activation with a new login or an activation just for the current shell. What do you think?

I like the idea about your CLI very much. What about a hidden configuration file outside of the nixup/nixuser configuration tree that is only managed by an CLI, and then sourced appropriately? I could imagine to have, e.g., ~/.nixup/profile/managed/{permanent,temporary} where packages are added or removed. The difference could be that the temporary packages are only available until the next rebuild of the declarative environment, whereas permanent packages are kept until they are removed. Could that work?

I was reading up on the mailing list again about your introduction of your PR, especially the question when to activate a new user environment. I think it should be possible to have different options like nixup switch or nixup login or nixup shell to distinguish between an immediate activation, an activation with a new login or an activation just for the current shell. What do you think?

The problem, is that as opposed to NixOS, we can have multiple instances of the shell, which can share some common configuration, such as agent program which are running in the background, as long as there is one session open.

Doing it for the current shell sounds interesting, but then the question is how do you ensure that the configuration files are only visible within the current shell and only within any application started by this shell.

Since I read about buildFHSUserEnv, I was wondering if we could use a mount-point namespace solution to make such testing mechanism possible. Then the question, is why do we have a different solution for the testing mechanism and the standard mechanism. If we are going that way, then we should do it for everything. The problem, is that mount-point namespaces are a Linux only feature, as far as know, which makes this unpractical for MacOS users.

I like the idea about your CLI very much. What about a hidden configuration file outside of the nixup/nixuser configuration tree that is only managed by an CLI, and then sourced appropriately?

Yes, that's what I was thinking about, which is to have a ~/.nixup/generated/user.packages.firefox.nix module generated when you install firefox from the command line. And do the same for every option which is defined from the command line.

Basically, the name of the file is used as a simple way to manipulate each definition without having any knowledge on how modules are written & handled.

I could imagine to have, e.g., ~/.nixup/profile/managed/{permanent,temporary} where packages are added or removed. The difference could be that the temporary packages are only available until the next rebuild of the declarative environment, whereas permanent packages are kept until they are removed. Could that work?

That's sounds doable, but I would not worry about that right now.

nbp · Aug 15, 2015

I was reading up on the mailing list again about your introduction of your PR, especially the question when to activate a new user environment. I think it should be possible to have different options like nixup switch or nixup login or nixup shell to distinguish between an immediate activation, an activation with a new login or an activation just for the current shell. What do you think?

The problem, is that as opposed to NixOS, we can have multiple instances of the shell, which can share some common configuration, such as agent program which are running in the background, as long as there is one session open.

Doing it for the current shell sounds interesting, but then the question is how do you ensure that the configuration files are only visible within the current shell and only within any application started by this shell.

Since I read about buildFHSUserEnv, I was wondering if we could use a mount-point namespace solution to make such testing mechanism possible. Then the question, is why do we have a different solution for the testing mechanism and the standard mechanism. If we are going that way, then we should do it for everything. The problem, is that mount-point namespaces are a Linux only feature, as far as know, which makes this unpractical for MacOS users.

I like the idea about your CLI very much. What about a hidden configuration file outside of the nixup/nixuser configuration tree that is only managed by an CLI, and then sourced appropriately?

Yes, that's what I was thinking about, which is to have a ~/.nixup/generated/user.packages.firefox.nix module generated when you install firefox from the command line. And do the same for every option which is defined from the command line.

Basically, the name of the file is used as a simple way to manipulate each definition without having any knowledge on how modules are written & handled.

I could imagine to have, e.g., ~/.nixup/profile/managed/{permanent,temporary} where packages are added or removed. The difference could be that the temporary packages are only available until the next rebuild of the declarative environment, whereas permanent packages are kept until they are removed. Could that work?

That's sounds doable, but I would not worry about that right now.

I've pushed an updated version of the declarative user environment. I tried to merge with #4594. Have a look and give me some feedback, please!

ts468 · Aug 23, 2015

I've pushed an updated version of the declarative user environment. I tried to merge with #4594. Have a look and give me some feedback, please!

(I haven't had the time read everything, so I hope I'm not saying something silly, or something already suggested.)

Is it planned to be able to hook into user environments from /etc/nixos/configuration.nix?

I'm thinking that if "~/.nixup/profile.nix" contains

{ config, pkgs, ... }:
{
  user.packages = with pkgs; [ vim firefox thunderbird ];
}

then a similar option can exist in /etc/nixos/configuration.nix (options gets merged):

{ config, pkgs, ... }:
{
  users.extraUsers.<name>.packages = with pkgs; [ vim firefox thunderbird ];
}

Basically, options in "~/.nixup/profile.nix" can be rooted in configuration.nix at "users.extraUsers..*" (or something like it).

bjornfor · Aug 23, 2015

(I haven't had the time read everything, so I hope I'm not saying something silly, or something already suggested.)

Is it planned to be able to hook into user environments from /etc/nixos/configuration.nix?

I'm thinking that if "~/.nixup/profile.nix" contains

{ config, pkgs, ... }:
{
  user.packages = with pkgs; [ vim firefox thunderbird ];
}

then a similar option can exist in /etc/nixos/configuration.nix (options gets merged):

{ config, pkgs, ... }:
{
  users.extraUsers.<name>.packages = with pkgs; [ vim firefox thunderbird ];
}

Basically, options in "~/.nixup/profile.nix" can be rooted in configuration.nix at "users.extraUsers..*" (or something like it).

@bjornfor Thanks for your interest! Indeed, it is planed to make all NixUP options that are available under "~/.nixup/profile.nix" also available in the NixOS configuration, probably under "users.extraUsers..profile". However, I'm just not so sure how to merge the options defined in NixOS and NixUP, yet. Should they just be added up? Should the options defined in NixOS be defaults that can be overwritten with NixUP, or should that be prohibited? If you have any suggestions or ideas that would be great! :)

ts468 · Aug 23, 2015

@bjornfor Thanks for your interest! Indeed, it is planed to make all NixUP options that are available under "~/.nixup/profile.nix" also available in the NixOS configuration, probably under "users.extraUsers..profile". However, I'm just not so sure how to merge the options defined in NixOS and NixUP, yet. Should they just be added up? Should the options defined in NixOS be defaults that can be overwritten with NixUP, or should that be prohibited? If you have any suggestions or ideas that would be great! :)

Basically, options in "~/.nixup/profile.nix" can be rooted in configuration.nix at "users.extraUsers..*" (or something like it).

This can be done quite easily, as by design modules are valid submodules.

nbp · Aug 24, 2015

Basically, options in "~/.nixup/profile.nix" can be rooted in configuration.nix at "users.extraUsers..*" (or something like it).

This can be done quite easily, as by design modules are valid submodules.

I would love to be able to use something like this on non-NixOS systems, fwiw. One can approximate it with buildEnv in ~/.nixpkgs/config.nix, but it would be very, very nice to have something that actually handles user dotfiles.

benley · Aug 29, 2015

I would love to be able to use something like this on non-NixOS systems, fwiw. One can approximate it with buildEnv in ~/.nixpkgs/config.nix, but it would be very, very nice to have something that actually handles user dotfiles.

anderspapitto · Aug 30, 2015

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto · Aug 30, 2015

nixup/lib/eval-config.nix

+# as subcomponents (e.g. the container feature, or nixops if network
+# expressions are ever made modular at the top level) can just use
+# types.submodule instead of using eval-config.nix
+{ # !!! system can be set modularly, would be nice to remove


can these first three (system, pkgs, baseModules) already be addressed (which I guess would mean removed, based on the comments?)

anderspapitto · Aug 30, 2015

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto · Aug 30, 2015

nixup/lib/from-env.nix

@@ -0,0 +1,4 @@
+# TODO: remove this file. There is lib.maybeEnv now


can this already be done?

anderspapitto · Aug 30, 2015

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto · Aug 30, 2015

nixup/modules/config/nix.nix

+
+    nix.package = mkOption {
+      type = types.package;
+      default = pkgs.nix;


what's another possible value that someone might want to set this to?

pkgs.nixUnstable

anderspapitto · Aug 30, 2015

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto · Aug 30, 2015

nixup/modules/config/packages.nix

+      '';
+    };
+
+    user.pathsToLink =


is this dead code due to the commented-out line 10 above?

anderspapitto · Aug 30, 2015

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto · Aug 30, 2015

nixup/modules/config/resourceFiles.nix

+      default = {};
+      type = types.loaOf (types.submodule options);
+      example = literalExample ''
+        [ { target = ".ssh/config";


could this be simplified to an attribute set where the key is the file name and the value is the string contents? Nix already has utilities for e.g. reading in file contents as a string (bulitins.readFile), so it seems unecessary to reinvent that with the "source" option

anderspapitto · Aug 30, 2015

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto · Aug 30, 2015

nixup/modules/misc/legacynixpkgsconfig.nix

+
+    in
+      # allow both:
+      # { /* the config */ } and


it would probably save some copy-pasting beginners some headache to only have one way (the second one)

anderspapitto · Aug 30, 2015

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto · Aug 30, 2015

nixup/modules/nixup/nixup.sh

+# If the Nix daemon is running, then use it.  This allows us to use
+# the latest Nix from Nixpkgs (below) for expression evaluation, while
+# still using the old Nix (via the daemon) for actual store access.
+if systemctl show nix-daemon.socket nix-daemon.service | grep -q ActiveState=active; then


systemctl is-active nix-daemon.socket
systemctl is-active nix-daemon.service

anderspapitto · Aug 30, 2015

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto · Aug 30, 2015

nixup/modules/nixup/nixup.sh

+fi
+
+
+# First build Nix, since NixOS may require a newer version than the


Can this logic be shared with the same logic for the NixOS-level?

anderspapitto · Aug 30, 2015

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto · Aug 30, 2015

nixup/modules/nixup/switch-to-configuration.pl

+            # Stopping a target generally has no effect on other units
+            # (unless there is a PartOf dependency), so this is just a
+            # bookkeeping thing to get systemd to do the right thing.
+            if (boolIsTrue($unitInfo->{'X-StopOnReconfiguration'} // "no")) {


Is all of this systemd-related logic copy-pasted from NixOS-level code?

jagajaga · Aug 30, 2015

jagajaga reviewed Aug 30, 2015

View changes

jagajaga · Aug 30, 2015

nixup/modules/nixup/switch-to-configuration.pl

@@ -0,0 +1,458 @@
+#! @perl@


We are trying to get rid of perl in nix...

@jagajaga What's the preferred language? Python?

C++
See this: https://www.bountysource.com/issues/4399291-get-rid-of-the-perl-dependency and NixOS/nix#341

Isn't that just for the nix core, not NixOS/nixpkgs

I think this issue can be related to this module.

@jagajaga We may be trying to get rid of Perl in Nix, but not in NixOS.

The first version does not have to be perfect, it just has to handle basic features on which we can iterate.

If you want to eliminate dead code, rewrite everything in another language, share the logic with other part of the repository, … then we can still do these after these modifications are merged.

The most important part is to have something which is working, and merged.
Do anybody see any blocker which might prevent this from working?

nbp · Aug 30, 2015

The first version does not have to be perfect, it just has to handle basic features on which we can iterate.

If you want to eliminate dead code, rewrite everything in another language, share the logic with other part of the repository, … then we can still do these after these modifications are merged.

The most important part is to have something which is working, and merged.
Do anybody see any blocker which might prevent this from working?

dezgeg · Aug 30, 2015

dezgeg reviewed Aug 30, 2015

View changes

dezgeg · Aug 30, 2015

nixos/modules/config/nixup.nix

+
+        # Activate nixup user profile.
+        if test -e $NIXUP_USER_PROFILE_DIR/default/activate; then
+            HOME=$PAM_HOME $NIXUP_USER_PROFILE_DIR/default/activate


Isn't this executing a user-controlled script as root?

dezgeg · Aug 30, 2015

dezgeg reviewed Aug 30, 2015

View changes

dezgeg · Aug 30, 2015

nixos/modules/installer/tools/nixos-install.sh

@@ -219,6 +219,7 @@ NIX_PATH="nixpkgs=/tmp/root/$nixpkgs:nixos-config=$NIXOS_CONFIG" NIXOS_CONFIG= \
 # Copy the NixOS/Nixpkgs sources to the target as the initial contents
 # of the NixOS channel.
 mkdir -m 0755 -p $mountPoint/nix/var/nix/profiles
+mkdir -m 1777 -p $mountPoint/nix/var/nix/profiles/nixup


Do we actually need a new subdirectory for nixup profiles? For instance, per-user channels use e.g. /nix/var/nix/profiles/per-user/root/channels

👍 for using per-user/$USER/nixup. It won't conflict with what's there and it is backwards compatible with current installations.

Thank you all very much for your feedback! Especially @nbp and @anderspapitto for your detailed review, it's highly appreciated! I will get back to it as soon as possible.

As Nicolas said, the current aim is to get something merged that we can build up on. That means, I'm particularly interested in suggestions concerning the "front-end", that is the interface that nixup modules are written against. The "back-end" stuff is mostly copied from NixOS and can be changed later without too much disruptions, I think.

Concerning the question of how to support non-NixOS systems. I think that basic functions like, e.g., the abstractions around nixpkgs, might be quite NixOS-independent, and so could work on other systems. When it comes to the support of nixup user services, I'm not so sure though. Like NixOS, it will be based around systemd, like it or not. So in order to make that feature available on non-NixOS systems, there would have to be a way to run a systemd user session, or something compatible at least. I don't know if projects like systembsd could be useful for that. But that won't be anything that I'll be working on.

ts468 · Aug 30, 2015

Thank you all very much for your feedback! Especially @nbp and @anderspapitto for your detailed review, it's highly appreciated! I will get back to it as soon as possible.

As Nicolas said, the current aim is to get something merged that we can build up on. That means, I'm particularly interested in suggestions concerning the "front-end", that is the interface that nixup modules are written against. The "back-end" stuff is mostly copied from NixOS and can be changed later without too much disruptions, I think.

Concerning the question of how to support non-NixOS systems. I think that basic functions like, e.g., the abstractions around nixpkgs, might be quite NixOS-independent, and so could work on other systems. When it comes to the support of nixup user services, I'm not so sure though. Like NixOS, it will be based around systemd, like it or not. So in order to make that feature available on non-NixOS systems, there would have to be a way to run a systemd user session, or something compatible at least. I don't know if projects like systembsd could be useful for that. But that won't be anything that I'll be working on.

dezgeg · Aug 30, 2015

dezgeg reviewed Aug 30, 2015

View changes

dezgeg · Aug 30, 2015

nixup/modules/nixup/nixup.sh

+}
+
+
+# Add a sensible default value for <nixup-config> to NIX_PATH.


nix-instantiate --find-file nixup-config could help to do this properly.

Min 10€, this would be awesome!

markus1189 · Aug 15, 2017

Min 10€, this would be awesome!

I've donated 50 EUR to the NixOS Foundation. (I'd like to see NixUP/Home manager integrated with Nix eventually. One CLI to rule them all.)

bjornfor · Aug 20, 2017

I've donated 50 EUR to the NixOS Foundation. (I'd like to see NixUP/Home manager integrated with Nix eventually. One CLI to rule them all.)

I'd give an easy 50 bucks. Brand new to NixOS but I fell in love so quickly. As others have said, user management is the major stumbling block for me right now in my learning curve.

WhittlesJr · Aug 20, 2017

I'd give an easy 50 bucks. Brand new to NixOS but I fell in love so quickly. As others have said, user management is the major stumbling block for me right now in my learning curve.

I would easily give 10€ (EDIT: Donated)

olejorgenb · Aug 20, 2017

I would easily give 10€ (EDIT: Donated)

FWIW, lots of dotfiles can be already replaced by wrappers like:

{
  users.users.root.packages = [
    (pkgs.writeScriptBin "htop" ''
      #! ${pkgs.bash}/bin/bash
      export HTOPRC=${pkgs.writeText "htoprc" ...}
      exec ${pkgs.htop}/bin/htop "$@"
    '')
  ];
}

Downside of the wrapper approach:

There might be applications that don't provide means to specify configuration. One could override $HOME, but then there might be applications that require $HOME for other stuff than configuration. (Personally, I haven't encountered any of these, yet.)
Applications cannot write their configuration anymore, e.g. htop will just terminate without error and nothing changed.

4z3 · Aug 21, 2017

FWIW, lots of dotfiles can be already replaced by wrappers like:

{
  users.users.root.packages = [
    (pkgs.writeScriptBin "htop" ''
      #! ${pkgs.bash}/bin/bash
      export HTOPRC=${pkgs.writeText "htoprc" ...}
      exec ${pkgs.htop}/bin/htop "$@"
    '')
  ];
}

Downside of the wrapper approach:

There might be applications that don't provide means to specify configuration. One could override $HOME, but then there might be applications that require $HOME for other stuff than configuration. (Personally, I haven't encountered any of these, yet.)
Applications cannot write their configuration anymore, e.g. htop will just terminate without error and nothing changed.

I'm currently trying out an approach leveraging rcm. I write a custom "dotFiles" package in my ~/.nixpkgs. The source includes both static files and nix code that produces dynamic ones, all of which end up in $out at the end. Then I write an install.nix with no build steps, but a shellHook ${rcm}/bin/rcup -v -d ${dotFiles}; exit, so it can be run with nix-shell.

I started doing this because I got sick of writing wrappers like the above, and even started running into programs that did not have a flag to override where they look for configuration.

nicknovitski · Aug 22, 2017

I'm currently trying out an approach leveraging rcm. I write a custom "dotFiles" package in my ~/.nixpkgs. The source includes both static files and nix code that produces dynamic ones, all of which end up in $out at the end. Then I write an install.nix with no build steps, but a shellHook ${rcm}/bin/rcup -v -d ${dotFiles}; exit, so it can be run with nix-shell.

I started doing this because I got sick of writing wrappers like the above, and even started running into programs that did not have a flag to override where they look for configuration.

I'm far from a NixOS expert, but I don't know if it's a good idea to put this into Nixpkgs master without testing it somewhere else first. As other people in this thread have mentioned there are already tools for managing dotfiles, and we can't know if NixUP will be better at this time.

Would it be possible to build this as a separate service or as a fork of Nixpkgs, and only merge it into master once we know it's the clear winner over the other options?

EDIT: For instance homemanager, which is mentioned in this thread.

seagreen · Sep 3, 2017

I'm far from a NixOS expert, but I don't know if it's a good idea to put this into Nixpkgs master without testing it somewhere else first. As other people in this thread have mentioned there are already tools for managing dotfiles, and we can't know if NixUP will be better at this time.

Would it be possible to build this as a separate service or as a fork of Nixpkgs, and only merge it into master once we know it's the clear winner over the other options?

EDIT: For instance homemanager, which is mentioned in this thread.

@ts468 - I donated €50 for this cause!

ixxie · Sep 8, 2017

@ts468 - I donated €50 for this cause!

To sum up we have

https://github.com/rycee/home-manager/
https://github.com/sheenobu/nix-home
nixup
I am looking for a solution where I could do programs.zsh.shellAliases = [ .. ] and it would generate it into $ZDOTDIR/.zshrc for instance.
nix-home looks very basic (like a versioned repo) while home-manager and nixup look better suited. I am tempted to go for the home-manager way as it seems easier to contribute (it has own repo with issues/PRs).

teto · Oct 5, 2017

To sum up we have

https://github.com/rycee/home-manager/
https://github.com/sheenobu/nix-home
nixup
I am looking for a solution where I could do programs.zsh.shellAliases = [ .. ] and it would generate it into $ZDOTDIR/.zshrc for instance.
nix-home looks very basic (like a versioned repo) while home-manager and nixup look better suited. I am tempted to go for the home-manager way as it seems easier to contribute (it has own repo with issues/PRs).

If anyone wants something waaaaaaaaaaay easier, then:

immutable user envs, declared in configuration.nix: https://github.com/michalrus/dotfiles/blob/f5045d2910d486e0ddc59aac7ca3715259abf573/nixos-config/modules/user-profiles.nix
very primitive dotfiles w/ “profiles” declared in configuration.nix (you can still use them easily on non-NixOS): https://github.com/michalrus/dotfiles/blob/bcc6d970c319568efc9ca25740d0d08f16217f6e/nixos-config/modules/dotfiles.nix
sample usage: https://github.com/michalrus/dotfiles/blob/bcc6d970c319568efc9ca25740d0d08f16217f6e/nixos-config/machines/desktop/base-mine.nix#L156-L160

Cheers,

michalrus · Oct 21, 2017

If anyone wants something waaaaaaaaaaay easier, then:

immutable user envs, declared in configuration.nix: https://github.com/michalrus/dotfiles/blob/f5045d2910d486e0ddc59aac7ca3715259abf573/nixos-config/modules/user-profiles.nix
very primitive dotfiles w/ “profiles” declared in configuration.nix (you can still use them easily on non-NixOS): https://github.com/michalrus/dotfiles/blob/bcc6d970c319568efc9ca25740d0d08f16217f6e/nixos-config/modules/dotfiles.nix
sample usage: https://github.com/michalrus/dotfiles/blob/bcc6d970c319568efc9ca25740d0d08f16217f6e/nixos-config/machines/desktop/base-mine.nix#L156-L160

Cheers,

A new and re-based version of NixUP arrived!

It would be great if you could review and test the changes!

Special attention should go into reviewing:

nixos-rebuild.sh (verify to have no effect on NixOS)
switch-to-configuration.pl (verify to have no effect on NixOS)
resource-manager.c (security review as resource-manager runs with setuid=0)

Many thanks in advance!

ts468 · Nov 6, 2017

A new and re-based version of NixUP arrived!

It would be great if you could review and test the changes!

Special attention should go into reviewing:

nixos-rebuild.sh (verify to have no effect on NixOS)
switch-to-configuration.pl (verify to have no effect on NixOS)
resource-manager.c (security review as resource-manager runs with setuid=0)

Many thanks in advance!

Hydra for tests: https://hydra.nixos.org/eval/1410967?compare=1405848

vcunat · Nov 16, 2017

Hydra for tests: https://hydra.nixos.org/eval/1410967?compare=1405848

This looks amazing. I also donated 50€.

Any progress since last comment?

davidak · Dec 16, 2017

This looks amazing. I also donated 50€.

Any progress since last comment?

@ts468 I see that I am being asked for review, but at the same time I see 2000 lines addition. Is there a way to split this work in multiple digest PR?

nbp · Jan 17, 2018

@ts468 I see that I am being asked for review, but at the same time I see 2000 lines addition. Is there a way to split this work in multiple digest PR?

bobvanderlinden · Jan 27, 2018

bobvanderlinden reviewed Jan 27, 2018

View changes

bobvanderlinden · Jan 27, 2018

nixos/modules/installer/tools/nix__-rebuild.sh

        showSyntax
        ;;
-      switch|boot|test|build|dry-build|dry-run|dry-activate|build-vm|build-vm-with-bootloader)
+      switch_*|boot_nixos|login_nixup|test_nixos|build_*|dry-build_nixos|dry-run_*|dry-activate_nixos|build-vm_nixos|build-vm-with-bootloader_nixos|edit_nixos)


Doesn't this (and changes of commandline flags below) break the existing usage of nixos-rebuild?

Sorry if I am asking something that should already be clear but is this:

@bjornfor Thanks for your interest! Indeed, it is planed to make all NixUP options that are available under "~/.nixup/profile.nix" also available in the NixOS configuration, probably under "users.extraUsers..profile". However, I'm just not so sure how to merge the options defined in NixOS and NixUP, yet. Should they just be added up? Should the options defined in NixOS be defaults that can be overwritten with NixUP, or should that be prohibited? If you have any suggestions or ideas that would be great! :)

still a feature you intend to add? I like to define my system using a single git repository and would rather not link stuff to home directories manually. I read in another message, that this, based on how it's implemented, might "automatically" work, but I am not proficient enough at nix to judge that.

throwup · Feb 1, 2018

Sorry if I am asking something that should already be clear but is this:

@bjornfor Thanks for your interest! Indeed, it is planed to make all NixUP options that are available under "~/.nixup/profile.nix" also available in the NixOS configuration, probably under "users.extraUsers..profile". However, I'm just not so sure how to merge the options defined in NixOS and NixUP, yet. Should they just be added up? Should the options defined in NixOS be defaults that can be overwritten with NixUP, or should that be prohibited? If you have any suggestions or ideas that would be great! :)

still a feature you intend to add? I like to define my system using a single git repository and would rather not link stuff to home directories manually. I read in another message, that this, based on how it's implemented, might "automatically" work, but I am not proficient enough at nix to judge that.

What is blocking this right now? Is there any way to help push this forward?

timokau · Feb 23, 2018

What is blocking this right now? Is there any way to help push this forward?

Yes, it is possible this gets into 18.03? Apart from some conflicts I don't see anything keeping it from merged

dasJ · Mar 5, 2018

Yes, it is possible this gets into 18.03? Apart from some conflicts I don't see anything keeping it from merged

@ts468 status?

IvanMalison · Apr 16, 2018

@ts468 status?

Is there a reason this has remained unmerged after nearly three years? The author's work is going to waste--it already needs another rebase and forward-porting effort now. It would be nice to at least hear from the Nix maintainers whether there are plans to integrate similar functionality.

drvink · Apr 22, 2018

Is there a reason this has remained unmerged after nearly three years? The author's work is going to waste--it already needs another rebase and forward-porting effort now. It would be nice to at least hear from the Nix maintainers whether there are plans to integrate similar functionality.

I personally think home-manager would be a better basis for this, as it is more featureful and actively developped

Nadrieril · Apr 22, 2018

I personally think home-manager would be a better basis for this, as it is more featureful and actively developped

Is there a reason this has remained unmerged after nearly three years? The author's work is going to waste--it already needs another rebase and forward-porting effort now. It would be nice to at least hear from the Nix maintainers whether there are plans to integrate similar functionality.

I personally think home-manager would be a better basis for this, as it is more featureful and actively developped

It would still be nice to hear something official from the maintainers, so that users of whichever system (be it nixup or homemanager) know which one is likely to be maintained and usable moving forward.

IvanMalison · Jun 4, 2018

Is there a reason this has remained unmerged after nearly three years? The author's work is going to waste--it already needs another rebase and forward-porting effort now. It would be nice to at least hear from the Nix maintainers whether there are plans to integrate similar functionality.

I personally think home-manager would be a better basis for this, as it is more featureful and actively developped

It would still be nice to hear something official from the maintainers, so that users of whichever system (be it nixup or homemanager) know which one is likely to be maintained and usable moving forward.

ts468 added the 9.needs: reporter feedback label Aug 14, 2015

ts468 referenced this pull request Aug 14, 2015
Closed
Make nix-modules available when defining user environments. #4493

jagajaga added old-label: documentation 6.topic: nixos labels Aug 14, 2015

ts468 requested a review from edolstra as a code owner Oct 30, 2017

ts468 requested a review from nbp as a code owner Nov 6, 2017

matthewbauer referenced this pull request Nov 9, 2017
Closed
.xoj mime-type does not get installed, when installing xournal via nix-env. #31328

GrahamcOfBorg added 10.rebuild-linux: 1-10 10.rebuild-darwin: 0 labels Nov 16, 2017

choochootrain referenced this pull request Dec 18, 2017
Open
integrate choochootrain/choochoo-toolkit #1

bobvanderlinden referenced this pull request Jun 13, 2018
Open
Initial home contents #41858
4 of 8 tasks complete

NixOS/nixpkgs

Join GitHub today

nixuser: declarative user environments #9250

Conversation

ts468 commented Aug 14, 2015

ts468 added the 9.needs: reporter feedback label Aug 14, 2015

ts468 referenced this pull request Aug 14, 2015

This comment has been minimized.

ts468 commented Aug 14, 2015

This comment has been minimized.

jgeerds commented Aug 14, 2015

This comment has been minimized.

jagajaga commented Aug 14, 2015

This comment has been minimized.

ts468 commented Aug 14, 2015

This comment has been minimized.

jagajaga commented Aug 14, 2015

This comment has been minimized.

dezgeg commented Aug 14, 2015

This comment has been minimized.

ts468 commented Aug 14, 2015

This comment has been minimized.

dezgeg commented Aug 14, 2015

This comment has been minimized.

nbp commented Aug 14, 2015

This comment has been minimized.

ts468 commented Aug 14, 2015

This comment has been minimized.

jagajaga commented Aug 14, 2015

jagajaga added old-label: documentation 6.topic: nixos labels Aug 14, 2015

This comment has been minimized.

copumpkin commented Aug 15, 2015

This comment has been minimized.

ts468 commented Aug 15, 2015

This comment has been minimized.

nbp commented Aug 15, 2015

This comment has been minimized.

ts468 commented Aug 15, 2015

This comment has been minimized.

nbp commented Aug 15, 2015

This comment has been minimized.

ts468 commented Aug 23, 2015

This comment has been minimized.

bjornfor commented Aug 23, 2015

This comment has been minimized.

ts468 commented Aug 23, 2015

This comment has been minimized.

nbp commented Aug 24, 2015

This comment has been minimized.

benley commented Aug 29, 2015

anderspapitto reviewed Aug 30, 2015 View changes

This comment has been minimized.

anderspapitto reviewed Aug 30, 2015 View changes

This comment has been minimized.

anderspapitto reviewed Aug 30, 2015 View changes

This comment has been minimized.

This comment has been minimized.

anderspapitto reviewed Aug 30, 2015 View changes

This comment has been minimized.

anderspapitto reviewed Aug 30, 2015 View changes

This comment has been minimized.

anderspapitto reviewed Aug 30, 2015 View changes

This comment has been minimized.

anderspapitto reviewed Aug 30, 2015 View changes

This comment has been minimized.

anderspapitto reviewed Aug 30, 2015 View changes

This comment has been minimized.

anderspapitto reviewed Aug 30, 2015 View changes

This comment has been minimized.

jagajaga reviewed Aug 30, 2015 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

nbp commented Aug 30, 2015

dezgeg reviewed Aug 30, 2015 View changes

This comment has been minimized.

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto reviewed Aug 30, 2015

View changes

anderspapitto reviewed Aug 30, 2015

View changes

jagajaga reviewed Aug 30, 2015

View changes

dezgeg reviewed Aug 30, 2015

View changes

dezgeg reviewed Aug 30, 2015

View changes

dezgeg reviewed Aug 30, 2015

View changes