Deprecate online flake registries

jade commented

2024-03-25 16:39:28 +00:00

Owner

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:

maybe fix #110 but after more thinking, it's not very important because doing this plan fixes this
add another layer of flake registry before online, perhaps "distribution", and lock the current state of the online flake registry in stone in the lix repo. make this a setting with a path in it and make the default this frozen online registry
default the flake registry option to empty string
print deprecation warnings for resolving through the online registry

Possible breakage from doing this:

people actually using that thing other than nixpkgs and expecting new stuff to appear? seems unlikely. but maybe people lock a specific revision in the registry, which would be foolish.
people setting it to something other than default now would have an overlay over the online one

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

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: 1. maybe fix https://git.lix.systems/lix-project/lix/issues/110 but after more thinking, it's not very important *because doing this plan fixes this* 2. add another layer of flake registry before online, perhaps "distribution", and lock the current state of the online flake registry in stone in the lix repo. make this a setting with a path in it and make the default this frozen online registry 3. default the flake registry option to empty string 4. print deprecation warnings for resolving through the online registry Possible breakage from doing this: * people actually using that thing other than nixpkgs and expecting new stuff to appear? seems unlikely. but maybe people lock a specific revision in the registry, which would be foolish. * people setting it to something other than default now would have an overlay over the online one 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: https://git.lix.systems/lix-project/lix/issues/170

❤️ 1

jade added the

ux

label 2024-03-25 16:39:28 +00:00

rbt commented

2024-03-25 17:46:57 +00:00

Owner

Can we keep the Flake registry for the CLI only? I agree that inputs.nixpkgs.url = "nixpkgs"; should never happen, but nix run nixpkgs#git -- ... is find and good (and I do in fact want it to always be the latest nixpkgs and not what my system is built with).

Can we keep the Flake registry for the CLI only? I agree that `inputs.nixpkgs.url = "nixpkgs";` should never happen, but `nix run nixpkgs#git -- ...` is find and good (and I do in fact want it to always be the latest `nixpkgs` and not what my system is built with).

gabriella439 commented

2024-03-25 17:52:35 +00:00

Owner

Or perhaps permit the use of the flake registry (in flake.nix) if the user supplies the --impure flag?

Or perhaps permit the use of the flake registry (in `flake.nix`) if the user supplies the `--impure` flag?

qyriad commented

2024-03-25 17:53:25 +00:00

Owner

Oh gods we don't need more basic daily usage commands that require --impure

Oh gods we don't need more basic daily usage commands that require `--impure`

gabriella439 commented

2024-03-25 18:01:42 +00:00

Owner

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 in flake.nix

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 in `flake.nix`

gabriella439 commented

2024-03-25 18:05:09 +00:00

Owner

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 in flake.nix. I think what I'm proposing is less disruptive than what @jade is proposing.

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 in `flake.nix`. I *think* what I'm proposing is less disruptive than what @jade is proposing.

qyriad commented

2024-03-25 18:08:27 +00:00

Owner

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

gabriella439 commented

2024-03-25 18:11:01 +00:00

Owner

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

qyriad commented

2024-03-25 18:56:46 +00:00

Owner

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

gabriella439 commented

2024-03-25 19:01:04 +00:00

Owner

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:

{ outputs = { nixpkgs, flake-utils, ... }: …

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 the NIX_PATH in general) is a footgun for production code.

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: ```nix { outputs = { nixpkgs, flake-utils, ... }: … ``` 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 the `NIX_PATH` in general) is a footgun for production code.

qyriad commented

2024-03-25 19:12:46 +00:00

Owner

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

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.

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

qyriad commented

2024-03-25 19:14:25 +00:00

Owner

(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)

(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)

jade commented

2024-03-25 19:23:33 +00:00

Author

Owner

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.

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.

gabriella439 commented

2024-03-25 19:24:03 +00:00

Owner

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)

jade commented

2024-03-25 19:34:54 +00:00

Author

Owner

Ok so registry indirect lookups currently go through three stages in descending preference order:

user specific registry, in home dir
system registry in /etc
online registry in https://github.com/nixos/flake-registry (!!) which is not pinned (!!!) and can change the target of indirections at any point.

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.

Ok so registry indirect lookups currently go through three stages in descending preference order: * user specific registry, in home dir * system registry in /etc * online registry in https://github.com/nixos/flake-registry (!!) which is not pinned (!!!) and can change the target of indirections at any point. 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.

gabriella439 commented

2024-03-26 14:51:43 +00:00

Owner

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.

jade commented

2024-03-26 20:57:51 +00:00

Author

Owner

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.

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

gabriella439 commented

2024-03-26 21:13:40 +00:00

Owner

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 to main as the trunk development branch. or do we plan to instead shadow that via higher-priority registry resolution mechanisms?

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` to `main` as the trunk development branch. or do we plan to instead shadow that via higher-priority registry resolution mechanisms?

jade commented

2024-03-26 21:25:23 +00:00

Author

Owner

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.