One open question is how the upgrade path for existing NixOS would look like. The change should be backward-compatible except for manual instructions. It would be nice if old users could use both the old and new notations.

I'm not voicing opinions yet for or against anything just laying out there some things I initially thought about.

I first wanted to point out the introductory paragraph, quickly read, reads like you're saying "nixos-unstable gets stuck, so let's use nixpkgs-unstable instead" which I think is not what you're saying. It might be a good idea to increase specificity there and say that you want to rename the installed channel's name, and not change the default selected channel.

The nix-channel manual says this about --add:

--add url [name]
Adds a channel named name with URL url to the list of subscribed channels. If name is omitted, it defaults to the last component of url, with the suffixes -stable or -unstable removed.

It will make the defaults for unstable kinda go against the grain of how nix-channel operates. Don't know if in reality it is an issue or not.

I'm curious: what is the status of this PR with regards to backwards compatibility? Any notes and ideas?

Things I see:

• nixos-rebuilds --upgrade
• command-not-found
• nix.nixPath option

Anything else I would have missed?

thanks @srhb!

thanks @samueldr for reading between the lines, your feedback is awesome. I agree that there are still unknowns to be uncovered and this is exactly the type of feedback I was looking for.

Can we somehow make installations with nix-env -iA nixos.hello throw an error like "error: nixos. has been changed to nixpkgs."? Because if not, we'd break a lot of installation instructions out there.

I think it's a good idea to make this more consistent.

nixos is also used on https://nixos.org/nixos/packages.html for example.

I think we should not change this at this time, because 1) it's an incompatible change; and 2) all of this will change anyway once we have flakes and a nix-channel replacement.

Closing then?

this will change anyway once we have flakes and a nix-channel replacement.

@edolstra can you say something about the status of that? Is there a chance it will be ready for the next release? When not we could still use this workaround in the next NixOS release until we have a clean solution. It might be a huge help for (new) Nix(OS) users.

What about aliasing those two in some way? (i.e. by default nixos == nixpkgs) EDIT: but yes, that would still be a breaking change for some cases.

@edolstra are there details published about the nix-channel replacement? flake.nix is still in early development and sounds good on paper.

At this point it seems easier to me to fix the existing NixOS system but happy to help on nix-channel instead. I would like to avoid having this PR blocked for a change that will happen 2 years down the line.

I think I found a backward-compatible way of tweaking the layout of ~/.nix-defexpr (which is the legacy folder nix-env uses instead of NIX_PATH). With that change in mind we would:

• Keep the nixos root channel
• But allow to use the nixpkgs. prefix in nix-env
• And change all the doc to point to the nixpkgs. prefix

TBC

$ nix-channel --list

$ sudo nix-channel --list
nixos https://nixos.org/channels/nixos-unstable

$ tree ~/.nix-defexpr/
/home/zimbatm/.nix-defexpr/
├── channels_root -> /nix/var/nix/profiles/per-user/root/channels
└── nixpkgs-compat
    └── nixpkgs -> /nix/var/nix/profiles/per-user/root/channels/nixos

$ nix search hello
warning: using cached results; pass '-u' to update the cache
* nixpkgs.gnome3.iagno (iagno-3.28.0)
  Computer version of the game Reversi, more popularly called Othello

* nixpkgs.hello (hello)
  A program that produces a familiar, friendly greeting
[...]
$ nix-env -iA nixpkgs.hello
installing 'hello-2.10'

The only issue is nix-env -qaP which lists both prefixes:

$ nix-env -qaP | head -n 6
nixpkgs._1password                                                       1password-0.5.4
nixos._1password                                                         1password-0.5.4
nixpkgs._2048-in-terminal                                                2048-in-terminal-2017-11-29
nixos._2048-in-terminal                                                  2048-in-terminal-2017-11-29
nixpkgs._20kly                                                           20kly-1.4
nixos._20kly                                                             20kly-1.4

The only issue is nix-env -qaP which lists both prefixes

Does that mean it also evaluates nixpkgs twice, or is that memoised? If it has to evaluate twice that's quite a pain…

It's evaluated twice when using nix-env -qaP. It went from 7s to 12s on my system. Since it will be replaced I think it's alright. For example nix search is not affected by that change either.

This PR has changed from switching the channel name to tweaking ~/.nix-defexpr to allow the unification of prefixes during nix-env -iA installs. I updated the PR description to reflect the new approach. This makes the PR backward-compatible and allows us to update and simplify the documentation.

As long as the command uses NIX_PATH instead of the old ~/.nix-defexprs it won't be impacted. I think that if the command uses ~/.nix-defexprs but specifies the prefix it won't be impacted either.

Not impacted by this PR:

• any of the new nix commands
• nixos-rebuild
• nix-build
• explicit <nixpkgs> imports

Impacted:

• nix-env -qaP

TODO: test the following commands:

• nix-env -iA nixos.hello (how to test this?)
• nix-shell -p hello (how to test this?)

Did I miss anything?

Modifying ~/.nix-defexpr from the login script is the kind of stateful, untracked configuration change that doesn't fit very well in NixOS.

Also given that many systems are already barely able to evaluate Nixpkgs, evaluating it twice isn't really an option.

I am currently blocked on resolving all the constraints:

1. Keep backward-compatible
2. Not rename the nixos channel
3. Not touch ~/.nix-defexpr
4. Avoid double nixpkgs evaluation on a subset of the old commands

Potential routes I can see:
a. Patch nix-env to alias nixpkgs to nixos if no nixpkgs prefix exists.
b. Help with the channel replacement (I don't know where that is?)

a) in short-term and having the channel replacement long-term, sounds like a good solution to me.