remove non-essential entries #52

NobbZ · 2024-01-02T16:47:53Z

This should be a good start to clean up the mess until #25 got some decission…

This should be a good start to clean up the *mess* until NixOS#25 got some decission…

zimbatm

A little bit too drastic, but makes sense overall.

The main argument to keep some of those is nix run and other invocations remain shorter.

zimbatm · 2024-02-08T09:06:16Z

flake-registry.json

-        "repo": "templates",
-        "type": "github"
-      }
-    },


This one is useful for nix flake init --template templates#foobar

I do not consider templates as they are any useful at all. But that is probably another topic that has to be dealt with in nixos/nix…

The Nix docs directly refer to the templates flake entry, e.g. it documents commands such as nix flake show templates and nix flake init -t templates#simpleContainer. So this shouldn't be removed.

I do not consider templates as they are any useful at all.

If you don't consider them useful, just don't use them, but also don't break them for other users.

zimbatm · 2024-02-08T09:07:58Z

flake-registry.json

-        "repo": "flake-utils",
-        "type": "github"
-      }
-    },


I suspect that removing flake-parts and flake-utils might cause some update issues for people

Why should it? I hope they have github:* in their flake inputs, not flake:* or implicit even… And if they did, they will now see why this was a bad idea at all.

The registry is for CLI usage only.

And if they did, they will now see why this was a bad idea at all.

I get your point, but I don't think we should punish users for using an under-documented feature wrong. Most users aren't experts and are copy-pasting things from other places.

Flakes are experimental, we are free to break related stuff. Lets just do it.

zimbatm · 2024-02-08T09:08:19Z

flake-registry.json

-        "repo": "home-manager",
-        "type": "github"
-      }
-    },


Let's keep home-manager given how important it is in our ecosystem

This one I could agree with.

zimbatm · 2024-02-08T09:08:53Z

flake-registry.json

-        "repo": "nixops",
-        "type": "github"
-      }
-    },


nix-darwin and nixops are both important projects

For nix-darwin I can agree, similar to how I agree with HM, though nixops, I am not sure about, given the state it seems to be in.

I am never sure if it is alive or not.

It's still an "official" project, but I agree that it's debatable. At the end, that kind of decision is probably subjective.

It is always subjective, thats why we really need some clear guidelines and policy as asked for in #25.

Both are true. Clear guidelines are useful because they help create a shared understanding of what should be included or not. But there are always grey where judgement calls are necessary.

zimbatm · 2024-02-08T09:09:32Z

flake-registry.json

-        "repo": "bundlers",
-        "type": "github"
-      }
-    },


Same argument for the bundlers as the templates

Do bundlers actually work?

Whenever I see or hear them used, it is trying to fix issues or "does not work".

Not sure :)

zimbatm · 2024-02-08T09:09:50Z

flake-registry.json

-        "repo": "default",
-        "type": "github"
-      }
-    },


Keep this one

I would agree if I could --override-inputs systems systems/darwin rather than having to --override-inputs systems github:nix-systems/darwin (or whatever the actual repo was)

And I would agree even more, if there was tab-completion for the branches on a flake.

why would this be kept? I wouldn't really call it essential, nor is it official, nor is it particularly helpful for the CLI

There is some utility to be able to write:

outputs = { self, nixpkgs, systems }: let eachSystem = nixpkgs.lib.genAttrs (import systems); in ...

Maybe it's not the cleanest, but it's nice to hack things quickly.

Making it easy is a good way to promote that pattern.

As said already, the registry really shouldn't be used in a flake.nix neither by explicit flke: inputs, neither by just adding things to the argumentset of the output function that haven't been explicitely defined in the inputs attribute.

This uses the registry implicitely. In the eyes of many a misfeature of nix.

For the CLI though the systems entry in the registry is rather useless, as shown in my example. It became more usefull if the repository would be redesigned to use branches rather than several individual repositories.

It is not clear to me though, whom or how exactly to contact though, thats why I will blindly ping @nix-systems hoping thats a pingable user and not an org…

NobbZ · 2024-02-08T09:31:39Z

Please feel free to close this one unmerged. It was created in anger when I realized that there was a seemingly stale discussion about a policy.

It was a semi-conscious decision to be overly drastic to deliver the message.

We need a policy, and we need to enforce it!

NobbZ · 2024-02-08T09:58:07Z

PS: The fact, that this PR went unnoticed for about a month, is another sign for how little love the registry appears to receive.

#25 has been appeared silent for ~8 months until I created the PR.

If the registry is an important piece of infrastructure, things need to be dealt with. If it is not, just shut it down or clean it up…

grahamc · 2024-02-08T12:57:54Z

Removing *anything* from the registry will break users who use the registry. I don’t think removing any entries is a good idea at all unless there is a migration period with nix support to indicate deprecation. Users of the registry don’t need to define an input for these, and will suddenly find themselves with broken flakes.

…

On Thu, Feb 8, 2024, at 4:58 AM, Norbert Melzer wrote: PS: The fact, that this PR went unnoticed for about a month, is another sign for how little love the registry appears to receive. #25 <#25> has been appeared silent for ~8 months until I created the PR. If the registry is an important piece of infrastructure, things need to be dealt with. If it is not, just shut it down or clean it up… — Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAASXLEXA34BWREELGKRXH3YSSOTXAVCNFSM6AAAAABBKI4BHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZTG4ZDIMZRGA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

NobbZ · 2024-02-08T13:15:32Z

As said, relying on the registry within a flake has never been a good idea for obvious reasons. Thats worse than channels…

For channels it was at least a concious act to add things. for the registry they are just there and no one understands why.

And let me repeat here, what I said in #52 (comment) and on many other occasions over the last 2 years:

Flakes are experimental, we are free to break them and related things. We should take this opportunity as long as the opportunity exists.

zimbatm · 2024-02-08T13:51:16Z

My expectation is that before merging we would:

Have a clear understanding of how things are going to break. Especially around nix flake update.
Document the breakage and migration path.
Announce it more widely, like a Discourse post and give it a week or so.

It doesn't have to be a super convoluted announcement, but let's be a bit respectful of users as well.

NobbZ · 2024-02-08T14:53:25Z

As said, this is not meant to be merged, but was a way to kick of the discussion again after the #25 staled.

I understand that some time for thought is required to take a closer look what should be kept or not.

I do not necessarily agree on putting time and effort into documenting and preparing a migration path. We seem to keep a papertrail of what we broke at some point in time, but we do not have a good documentation of the status quo.

I might repeating myself but, flakes are explicitely marked as experimental. They scream "I will break when you need it least, do not use me in production".

We should just break things. Or remove the "experimental" status, even though poeple seem to be deaf for my arguments…

zimbatm · 2024-02-11T13:16:46Z

Ok, so based on the feedback, are you able to propose an updated inclusion policy?

edolstra · 2024-02-12T12:05:31Z

I'm not in favor of removing entries until #25 gets resolved. There is no clear benefit to removing entries right now, but there are potential downsides.

As said, relying on the registry within a flake has never been a good idea for obvious reasons.

If you don't want to rely on the registry, you don't have to - just don't use it. That's no argument for breaking it for other users who do find it useful.

I might repeating myself but, flakes are explicitely marked as experimental.

They are, but we're also in the stabilization phase. That is, we don't try to break stuff unless we have to.

remove non-essential entries

18e9a09

This should be a good start to clean up the *mess* until NixOS#25 got some decission…

sedlund mentioned this pull request Feb 3, 2024

Policy for inclusion in the flake registry #25

Open

zimbatm reviewed Feb 8, 2024

View reviewed changes

edolstra closed this Feb 12, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

remove non-essential entries #52

remove non-essential entries #52

NobbZ commented Jan 2, 2024

zimbatm left a comment

zimbatm Feb 8, 2024

NobbZ Feb 8, 2024

edolstra Feb 12, 2024

zimbatm Feb 8, 2024

NobbZ Feb 8, 2024

zimbatm Feb 8, 2024

NobbZ Feb 8, 2024

zimbatm Feb 8, 2024

NobbZ Feb 8, 2024

zimbatm Feb 8, 2024

NobbZ Feb 8, 2024

zimbatm Feb 8, 2024

NobbZ Feb 8, 2024

zimbatm Feb 11, 2024

zimbatm Feb 8, 2024

NobbZ Feb 8, 2024

zimbatm Feb 8, 2024

zimbatm Feb 8, 2024

NobbZ Feb 8, 2024

eclairevoyant Feb 8, 2024 •

edited

Loading

zimbatm Feb 8, 2024 •

edited

Loading

NobbZ Feb 8, 2024

NobbZ commented Feb 8, 2024

NobbZ commented Feb 8, 2024

grahamc commented Feb 8, 2024 via email

NobbZ commented Feb 8, 2024 •

edited

Loading

zimbatm commented Feb 8, 2024

NobbZ commented Feb 8, 2024

zimbatm commented Feb 11, 2024

edolstra commented Feb 12, 2024 •

edited

Loading

remove non-essential entries #52

remove non-essential entries #52

Conversation

NobbZ commented Jan 2, 2024

zimbatm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eclairevoyant Feb 8, 2024 • edited Loading

Choose a reason for hiding this comment

zimbatm Feb 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NobbZ commented Feb 8, 2024

NobbZ commented Feb 8, 2024

grahamc commented Feb 8, 2024 via email

NobbZ commented Feb 8, 2024 • edited Loading

zimbatm commented Feb 8, 2024

NobbZ commented Feb 8, 2024

zimbatm commented Feb 11, 2024

edolstra commented Feb 12, 2024 • edited Loading

eclairevoyant Feb 8, 2024 •

edited

Loading

zimbatm Feb 8, 2024 •

edited

Loading

NobbZ commented Feb 8, 2024 •

edited

Loading

edolstra commented Feb 12, 2024 •

edited

Loading