-
-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC 0147] Redefine unstable version format and comparison #147
Conversation
9006913
to
e0c173d
Compare
e0c173d
to
04a01c4
Compare
Woohoo! Can I drop the older one? :3 |
I mean, if you're asking me, I'm a nobody and this is my first RFC; you're a committer and have worked on several. I defer entirely to your judgment. Maybe having two approaches in parallel makes it more likely that one will succeed, and 107 is farther along than this, obviously. But if you're sick of trying to keep 107 going, that would make sense to me also. |
If you as the author think that this RFC is preferable feel free to close the old one. It can always be reopened to copied to a new RFC if interest in that approach reappears. |
I rather we stop using Then we don't have to create any specifial cases for "unstable", right? |
Example? How would you compare |
Alternately, we could deprecate Either way, |
So much for Nixpkgs could have its own version comparison logic, deviating from |
So much for `nix-env`. What should a Nixpkgs package do if it wants to compare the version of a dependency against a known version string, to permit/forbid the derivation or to enable/disable a feature or patch? If my package uses `lib.versionAtLeast some-dep.version "1.2.1"`, and `some-dep.version` is either `"unstable-2023-05-27"` (status quo) or `"1.2-unstable-2023-05-27"` (NixOS/nixpkgs#234201), how do we get the result of the `versionAtLeast` call to be false?
This was discussed at length in the previous RFC, but basically: you cannot have a single function that compares versions correctly for arbitrary packages, because different packages have different conventions.
It's actually very rare (if it even happens at all) that this situation would come up in Nixpkgs. Usually, we package some number of stable versions of a package (often 1), and sometimes a single unstable version (usually HEAD). In which case to distinguish patches that should only be applied to unstable, you can just pass an "unstable" boolean argument to your common builder function, or you can check if the version starts with "unstable". To apply patches only to some stable versions, you can use lib.versionAtLeast or lib.versionOlder if they work for that particular package's versioning scheme, but if they don't (because they _can't_ work for every package), that's okay too. For uncommon cases, you can implement the specific logic needed by those packages.
|
And you do not even need So the only part that is could be needed is prefixing the version string with the last stable version for unstable packages. Which is precisely the bikeshed-prone part #107 got stuck on. |
That's true, and I had thought it wasn't. Mea culpa. Yeah, great, if we can ignore |
#107, any% speedrun
Rendered