Policy for inclusion in the flake registry about flake-registry HOT 14 OPEN

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.

from flake-registry.

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.

from flake-registry.

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

from flake-registry.

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?

from flake-registry.

#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.

from flake-registry.

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.

from flake-registry.

#43 introduces an inclusion policy that is quite strict.

from flake-registry.

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

from flake-registry.

I think we should accept org/user namespaces instead of package namespaces.
For current implementation means the org, will have at least one centralized flake to:

• or be its monorepo (like nixpkgs)
• or re-export its inputs.

Proof of Concept
This would let me use "cruel-intentions" as URL instead of "github:cruel-intentions/devshell-files"
Also, anyone could run "nix run cruel-intentions" or "nix run cruel-intentions#patavinas".

That makes a lot of sense for companies like flox, cachix, detsys, numtide, holpefully someday mysql, oracle, steam, etc

• That would keep this feature more useful from UX perspective for users,
• Won't make this feature an untouchable point of nix (unless I have the most impressive/acclaimed/useful/etc flake)
• Reduce the collision, we know that the only way to have almost zero collisions is using hashes (bad for UX)

Related:

• https://docs.npmjs.com/about-scopes
• https://github.com/nix-community/NUR

DockerHub has good and bad examples:

• https://hub.docker.com/u/nixos (good we are not required to be important to docker community to have one namespace)
• https://hub.docker.com/u/nixpkgs (bad causes confusion or could be anyone else disguised as NixOS org)
• https://hub.docker.com/_/golang (official example)

Repo jacking: Most flake operations are in danger, not only with flake registry (unless someone with like me has access to it).

• Flake author can change his github user/org name
• Anyone else can adopt his old name
• And act like him. Recreate his repositories.
• Next nix flake update, you may not take input from the same author.
• "nix run cruel-intentions" or "nix run github:cruel-intentions/devshell-files" has the same flaw.

At least I could open a PR to update flakes-registry pointing to my new user (requiring another issue for name changing policy).

from flake-registry.

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

from flake-registry.

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 .

from flake-registry.

I agree with comments from @bew and @Zimmi48 . The comments look to be supported by others. The pr #52 looks to implement this.

Do we agree? If so, can the readme reflect these comments and the pr merged?

from flake-registry.

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.

from flake-registry.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/call-for-volunteers-curating-official-projects/45382/6

from flake-registry.