Policy for inclusion in the flake registry

[zimbatm]

What policy should we adopt for inclusion in the flake registry?

Should we allow any references that are getting submitted? Or do we have some criteria for inclusion?

Some facts:

• The registry is a global namespace and will hit naming collisions at some point
• The registry is not strictly necessary. It's mainly a shorthand notation.

This issue was triggered by #24. It seems to be just a normal tool, not specific to Nix.

Once we agree I will create a README and add the policy to it

[Zimmi48]

I tried to alert about the need for a policy for the flake registry and tried recommending deferring this to a later RFC in NixOS/rfcs#49 (review), but apparently I did not succeed in being heard. IMHO this issue is important.

[arcuru]

The PR linked in the initial post, #24, was merged after this post was made, despite it being a 10 star repo and the tool being available in nixpkgs. I personally think it's distinctly odd that tools available in nixpkgs are being added as top-level entries here, the global registry probably shouldn't be a copy of https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix

I agree with @Zimmi48, if the global registry is going to exist an RFC is needed to determine the policy. And to be very clear, adding things to the global registry now and later saying "we can't remove it because it's already there" is not an acceptable solution.

If there isn't going to be a policy before stabilizing flakes, I'd strongly suggest removing everything questionable (tools already in nixpkgs, the personal projects clearly just used for initial testing, etc) ASAP even if they need to be re-added back later.

[Minion3665]

The PR linked in the initial post, #24, was merged after this post was made, despite it being a 10 star repo and the tool being available in nixpkgs. I personally think it's distinctly odd that tools available in nixpkgs are being added as top-level entries here, the global registry probably shouldn't be a copy of https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix

I agree with @Zimmi48, if the global registry is going to exist an RFC is needed to determine the policy. And to be very clear, adding things to the global registry now and later saying "we can't remove it because it's already there" is not an acceptable solution.

If there isn't going to be a policy before stabilizing flakes, I'd strongly suggest removing everything questionable (tools already in nixpkgs, the personal projects clearly just used for initial testing, etc) ASAP even if they need to be re-added back later.

++ looking back, I think #24 probably shouldn't have been merged.

Unlike search (which I think probably should index public flakes), registry does go onto everyone's system so its policy for inclusion should be tighter, and I am now of the opinion that nix-specific stuff (and nothing else) should be included (stuff like flake-utils, nixpkgs, nur, etc.). If people would like me to make a reverting PR I can, or alternatively anyone else can do it

[arcuru]

If people would like me to make a reverting PR I can

@Minion3665 I don't think that's necessary, if the owners feel it should be removed because of a policy update they can do it themselves.

[oxalica]

I'm personally against the idea of an auto-updating global registry, and I always overrided the global registry to a file since I'm in a country with poor connection latency to github.com or nixos.org. The global registry behaves like a list of "well known projects", opens the hole of supply chain attack and is worse than a default value of system registry nix.registry inside nixpkgs.

So IMO, when we do have a "global" registry, nothing other than NixOS/nixpkgs itself should be suitable.

[Minion3665]

I'm personally against the idea of an auto-updating global registry, and I always overrided the global registry to a file since I'm in a country with poor connection latency to github.com or nixos.org. The global registry behaves like a list of "well known projects", opens the hole of supply chain attack and is worse than a default value of system registry nix.registry inside nixpkgs.

So IMO, when we do have a "global" registry, nothing other than NixOS/nixpkgs itself should be suitable.

I mostly agree, although I feel having some projects other than Nixpkgs is nice

I'd be far more convinced if the policy were "nothing not in nix-community or nixos" (or even just the nixos org). A policy like that would allow maintained and relevant projects like hydra or home-manager to stay while still having more oversight than "anybody's GitHub repo" (although admittedly particularly nix-community inclusion does not guarantee no supply chain attacks).

I personally have the registry as a flake input to stop it updating automatically; I find it a little grating if nix downloads the registry without me wanting it to

[oxalica]

I mostly agree, although I feel having some projects other than Nixpkgs is nice ... like hydra or home-manager ...

A default value of system registry nix.registry maintained inside nixpkgs can also do this. Or to be better, a nix.enableDefaultRegistry option, to mimic fonts.enableDefaultFonts .

[bew]

Note that since NixOS/nix#5420 we can disable the global registry by setting flake-registry to "" 😃

[zimbatm]

#43 introduces an inclusion policy that is quite strict.

[bew]

Looks great 👍
With regards to that, I think some entries should be removed as they're not contributing much to the nix ecosystem, there're more like ads than anything else..

I'm talking about:

• agda
• composable (specific to finances)
• gemini
• pridefetch (a system stats for lgbt&co ppl)
• helix (a text editor)

There are also many entries that are quite specific to languages (like nimble or fenix entries) or projects like Hydra (hercule-ci-effects entry and others) that looks a bit too specific to me and not really useful for most people I think.
It feels to me like accepting those would open the gates to have all language builders/pkgs or hydra/.. extensions for not much benefit (and super long registry)..

What do you think?

[Zimmi48]

#43 introduces an inclusion policy that is quite strict.

I would suggest being stricter and:

1. Excluding most flakes that are convenience to get a single package (one could then wonder why the default way of getting access to this package is through a flake and not through nixpkgs). It seems more justified to include flakes that provide access to a registry of application-specific packages like nix-community/flake-nimble or nix-community/emacs-overlay.
2. Having some "official flake" criterion. One shouldn't be able to submit a flake for a well-known project linking to some random / untrusted repo. The repo should either be an official repo maintained by the project itself, or a nix-community or NixOS repo. Otherwise, this creates a risk that users will start trusting some random flake just because it is listed in the flake registry, even though there was no validation process for whether this random flake can actually be trusted.

I also agree that since flakes are still an experimental feature, it's not too late to clean the registry from flakes that do not meet the policy.