Deprecate online flake registries #183
Labels
No labels
Area/build-packaging
Area/cli
Area/evaluator
Area/flakes
Area/language
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/store
bug
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
RFD
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
ux
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#183
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The online flake registry is a potential tool of hegemony and is a bad idea for the majority of use cases anyway because it shifts under your feet. It's certainly possible someone uses an online flake registry other than the default and unfortunately we probably don't want to break that immediately at least.
Plan:
Possible breakage from doing this:
Alternative implementation strategy (which i think is actually better): make the online flake registry setting accept a path. Then we do the same thing and delete the flake registry by default with very little work and only the first category of users above would ever break. Good riddance.
Related: #170
Can we keep the Flake registry for the CLI only? I agree that
inputs.nixpkgs.url = "nixpkgs";
should never happen, butnix run nixpkgs#git -- ...
is find and good (and I do in fact want it to always be the latestnixpkgs
and not what my system is built with).Or perhaps permit the use of the flake registry (in
flake.nix
) if the user supplies the--impure
flag?Oh gods we don't need more basic daily usage commands that require
--impure
I think it wouldn't be basic daily usage, though? I'm not proposing that the CLI would require the
--impure
flag to use the flake registry. Only if you used the flake registry inflake.nix
Or to put it another way: my understanding is that @jade is proposing to ban the use of the flake registry in
flake.nix
whereas I'm proposing to instead just require--impure
to use the flake registry inflake.nix
. I think what I'm proposing is less disruptive than what @jade is proposing.Ah I understand what you're saying now yes. It would be less disruptive, but I don't really see the point. Indirect lookup to write a lockfile isn't a great idea and we'd rather just give an easy migration to something better
I mean, you could make a similar argument against most things that rely on the
--impure
flag (like reading environment variables or local filesystem paths), but I don't think we're proposing to ban those other things or the--impure
flag altogether? If those things are supported under the--impure
flag then it seems reasonable to me to also support indirect flake registries which are no worse than those other impure Nix features. It seems weird to hit the flake registry with a heavier ban hammer than the other impure stuff.I don't think reading environment variables and local paths is really in the same category as the flake registry. Impure evaluation is very often something you genuinely want — even if you want to be explicitly aware of when you're doing it — but looking up an indirect flake name in a
flake.nix
— and especially then writing it to a lockfile — is just short of a footgun.I'm a little biased here because I actually use the indirect flake input feature all the time for quick and dirty local testing. I'll often do:
It's basically analogous to how a lot of people will do
let pkgs = import <nixpkgs> { }; in …
when not using flakes for quick and dirty testing even though<nixpkgs>
(or using theNIX_PATH
in general) is a footgun for production code.I would like to note that this is about the online flake registry — #170 would be the issue to discuss about writing that kind of thing in
flake.nix
. If online flake registries were banned but #170 didn't happen then you could still just use the local registry path that jade is suggesting(Also, imo,
NIX_PATH
is a different kind of broken than the online flake registry, since at least theoretically<nixpkgs>
points to whatever your Nixpkgs channel has and — without overriding it — only changes with channels' mutable state)I think everyone has misread the intent here. I want to eliminate the practice of making network connections to determine how to indirect a command line argument. I do agree this mechanism is necessary and I don't want to remove it, I just want to kill the part where it is making network connections to determine indirections by default.
I also want to stop using registries to indirect anything inside a flake.nix file.
Can you explain a bit more then? I don't understand what the online flake registry is if it's different from the flake registry. More generally, I think perhaps I don't understand what is being proposed here (even after carefully re-reading the original description)
Ok so registry indirect lookups currently go through three stages in descending preference order:
I want to deprecate the last one as an online thing by freezing it in time and shipping that frozen one with Lix, and using that frozen state in place of the online state. This is because it has unclear name assignment and rules and is not significantly used, and it's unclear when a project is significant enough to be included such that nix run project#meow works. Realistically most people just use it for nixpkgs aliases, which is fine and we don't want to break. If you want your own indirections as shortcuts locally you can just use nix registry pin on your own computer or some json editing to do it.
This deprecation is unrelated to deprecating registry indirect flake inputs, which we also want to do.
Ah, okay, that makes sense. I agree that the online registry doesn't provide a lot of value: the entries there change slowly enough (almost never?) that changing them at lix upgrade time should be enough to handle most use cases.
We would actually prefer to eliminate the mechanism entirely for future uses, that is, we don't intend to update it in the lix source tree ever. But yes, this would improve UX especially offline and make things more predictable for the most part.
i think the one case where i can see wanting to change it is if, say, one of the repos in the registry were to ever change from
master
tomain
as the trunk development branch. or do we plan to instead shadow that via higher-priority registry resolution mechanisms?Ah, ok, yeah. I would change it in such cases and send a patch release tbh. But the point is to not allow new projects to use it.
would also fix #116