Describe the bug

The flake registry is global mutable state that's outside the view of beginners.
NixOS is supposed to be the distro without such mutable magic.

The global flake registry is mostly append-only, so it usually won't cause problems. This is mostly about the system flake registry.

Steps To Reproduce

(edited:)

• See for example Installer doesn't update nixpkgs flake input correctly nixpkgs#204292

• Different users may get different results even if they run nix flake update at the same time on such a flake, due to differing nixpkgs entries in system or user registries; (@balsoft)

• If you have an unusual flake in your system/user registry, you might accidentally use it in the arguments of outputs, and now others can't nix flake update at all; (@balsoft)

• [Assuming we keep some registries, the system and user ones] breaks a nice setup with settings nixConfig.flake-registry in the flake, since system/user registry entries override the global registry entries set by flake-registry. (@balsoft)

Expected behavior

nix flake update always behaves the same.

(edited:)

Possible solutions

There's a matrix of things we can do here.
On the first axis, to what degree do we remove it?

• Remove
• Deprecate
• Feature flag
  • allows flakes to stabilize sooner
• Put behind a disabled nix.conf option
  • discourages use
• Recommend not to use unless absolutely necessary, in docs
  • discourages use slightly
• Do not set any "default" registry entries in anywhere in NixOS
  • does not discourage use

On the second axis, which registries are bad?

• All registries
• Per-process registry, --override-flake
• Per-flake registry (has this been properly implemented?)
• Per-user registry
• Per-system registry
• Per-internet registry, aka NixOS/flake-registry. Airgapped networks may have their own.

Let's start with "all registries". This is perhaps too radical, but it could be argued that any mechanism is too complicated; that we should keep things simple and composable, by emphasizing local files and small commands with very few responsibilities. For example, niv does not implement an impurely overridable update mechanism, and I couldn't find such a feature request either.

The per-process case seems harmless because the caller is explicit about the intent. There's no "action at a distance".
The per-internet one also seems harmless because it is managed with care and the outcome will be the same for everyone. Airgapped users have their own expectations. We should document how they should manage their registry.

A per-flake registry does involve "action at a distance", but will lead to the same result for everyone.

The per-user and per-system registries are bad, because they are both "action at a distance" and lead to different results for different people.

My current preference is to:

• Remove the system and user registries
• Put the registry feature behind a feature flag
• Make nix run /etc/nixpkgs#hello possible

nix-env --version output

Additional context

I'll use this section to summarize what I believe are the most relevant comments.

We must keep some variant of it otherwise nix shell nixpkgs#hello would not work.

I propose /etc/nixpkgs#hello as an alternative for those who want to pin the nixpkgs version they use on the command line.

Unprivileged users may use ~/nixpkgs if they want to manage their own command line pin.

Unpinned scripts may use e.g.

#!/usr/bin/env nix
#!nix run github:NixOS/nixpkgs/stable#python

# python code here

a common registry for many flakes within the same context (e.g. organization)

"nice setup" allows us to have a common registry for many flakes within the same context (e.g. organization). This is nice for two reasons:

• No need to type in inputs.bar.url = "github:foo/bar" for dozens of flakes = a lot less boilerplate
• The ability to withhold updates of certain inputs (think haskell.nix or nixpkgs) company-wide to prevent mass rebuilds, while keeping the rest up-to-date with daily nix flake update, and also the ability to update those inputs simultaneously over many flakes, resulting in potentially significant savings in build time and nix store space usage.

Valid reasons to allow and perhaps improve the nixConfig.flake-registry feature. It is still action at a distance though, and if this organization publishes their registry and projects as open source, unsuspecting users may be confused why their fork doesn't update.

But is it really mutable state?

Technically yes, because the registry information comes from mutable places.
In practice, also yes, because the registry usually isn't pinned to e.g. a project.
I'll stop here and not discuss the definition of this term any further. If you prefer another definition of mutable, you may read and discuss the issue equally well without that introductory sentence.

Priorities

Add 👍 to issues you find important.