lix-project/lix and lix-project/nixos-module flakes disagree about lix prerelease version formatting #585

New issue

Open

opened 2024-11-25 04:17:25 +00:00 by lilyball · 4 comments

lilyball commented

2024-11-25 04:17:25 +00:00

Member

Describe the bug

The lix-project/lix flake produces a package with a version formatted like 2.92.0-devpre20241120_66f6dbd. Meanwhile the lix-project/nixos-module flake configures the package to have a version formatted like 2.92.0-dev-pre20241120-66f6dbd. They're almost identical, the difference is the nixos-module one puts a dash at the start of the suffix that the lix flake doesn't. They also differ in the punctuation used to separate the git hash at the end, though that's less likely to interfere with anything.

This is a problem for code that wants to do version comparisons that include prerelease versions, for example nix-darwin is using a version comparison to disable auto-optimise-store unless the nix package includes the relevant fix. That code is comparing against the version 2.92.0-devpre20241107, meaning it will work for anyone getting Lix from the lix flake directly, but won't work for anyone getting it from the nixos-module flake.

Steps To Reproduce

> nix eval git+https://git.lix.systems/lix-project/nixos-module#default.version
"2.92.0-dev-pre20241115-c859d03"
> nix eval git+https://git.lix.systems/lix-project/lix#nix.version
"2.92.0-devpre20241120_66f6dbd"

Expected behavior

Both of those nix evals should produce versions that are formatted the same.

## Describe the bug The lix-project/lix flake produces a package with a version formatted like `2.92.0-devpre20241120_66f6dbd`. Meanwhile the lix-project/nixos-module flake configures the package to have a version formatted like `2.92.0-dev-pre20241120-66f6dbd`. They're almost identical, the difference is the nixos-module one puts a dash at the start of the suffix that the lix flake doesn't. They also differ in the punctuation used to separate the git hash at the end, though that's less likely to interfere with anything. This is a problem for code that wants to do version comparisons that include prerelease versions, for example nix-darwin is using a version comparison to [disable `auto-optimise-store`](https://github.com/LnL7/nix-darwin/blob/f0a1269297c8ca7f5aa287166c2a9cfb6e13917c/modules/nix/default.nix#L770) unless the nix package includes the relevant fix. That code is comparing against the version `2.92.0-devpre20241107`, meaning it will work for anyone getting Lix from the lix flake directly, but won't work for anyone getting it from the nixos-module flake. ## Steps To Reproduce ```console > nix eval git+https://git.lix.systems/lix-project/nixos-module#default.version "2.92.0-dev-pre20241115-c859d03" > nix eval git+https://git.lix.systems/lix-project/lix#nix.version "2.92.0-devpre20241120_66f6dbd" ``` ## Expected behavior Both of those `nix eval`s should produce versions that are formatted the same.

lilyball added the

bug

Area/build-packaging

labels

2024-11-25 04:17:26 +00:00

jade commented

2024-11-25 18:55:26 +00:00

Owner

woooops. this should be really easy to fix though.

jade added the

E/easy

label

2024-11-25 18:55:38 +00:00

lilyball commented

2024-11-25 19:16:40 +00:00

Author

Member

It should, the question is just which format to standardize on.

lilyball commented

2024-11-25 19:38:00 +00:00

Author

Member

Hmm, here's a wrinkle:

nix-repl> builtins.compareVersions "2.92.0-dev-pre-20241120" "2.92.0"
1

nix-repl> builtins.compareVersions "2.92.0-devpre-20241120" "2.92.0"  
1

nix-repl> builtins.compareVersions "2.92.0-pre-20241120" "2.92.0"    
-1

We should probably not standardize on either format but instead change the format to start with "pre" since that's treated specially by version comparison. Here's my suggestion for a new format: 2.92.0-pre-20241120_gabc123 (where gabc123 is the hash we're sticking on the end). We could also optionally have the lix flake append -dev to the end (before the hash) if we want to try and identify versions from local development, ideally only doing this when built with devShell.

With the optional -dev bit that would make the lix module emit 2.92.0-pre-20241120_gabc123 and the lix flake emit 2.92.0-pre-20241120-dev_gabc123. The idea of putting -dev there is that it shouldn't interfere with version comparisons.

I think this means changing the version.json file to list the version as "2.92.0-pre", but also changing both flakes to change the versionSuffix.

Hmm, here's a wrinkle: ```nix nix-repl> builtins.compareVersions "2.92.0-dev-pre-20241120" "2.92.0" 1 nix-repl> builtins.compareVersions "2.92.0-devpre-20241120" "2.92.0" 1 nix-repl> builtins.compareVersions "2.92.0-pre-20241120" "2.92.0" -1 ``` We should probably not standardize on either format but instead change the format to start with "pre" since that's treated specially by version comparison. Here's my suggestion for a new format: `2.92.0-pre-20241120_gabc123` (where `gabc123` is the hash we're sticking on the end). We could also optionally have the lix flake append `-dev` to the end (before the hash) if we want to try and identify versions from local development, ideally only doing this when built with devShell. With the optional `-dev` bit that would make the lix module emit `2.92.0-pre-20241120_gabc123` and the lix flake emit `2.92.0-pre-20241120-dev_gabc123`. The idea of putting `-dev` there is that it shouldn't interfere with version comparisons. I think this means changing the `version.json` file to list the version as `"2.92.0-pre"`, but also changing both flakes to change the `versionSuffix`.

jade commented

2024-11-26 06:45:03 +00:00

Owner

Seems reasonable. Feel free to submit the change and I'll stamp it.,