I'm not a big fan of including unsable in the pname. If I have "package a", it will still be a "package a" if I select a different release or commit. The package name should stay the same, but declare the difference through the version tag.

i agree that it would make sense that pname match the upstream name, but that is currently the official documented rule

i think this change was needed for repology. not sure if it is still needed @jtojnar

When a revision is used instead of a reference or explicit release, it not always means it corresponds to an unstable version. The unstable' addition to the name is to indicate the unstable variant, as @jonringer points out, to differentiate from the stable version. Sometimes, we need to fetch a revision because using patches is not workable. Changing the pname affects nix-env users.

Changing the pname affects nix-env users.

nix-env users are already in a tough spot, even from something like many similar packages being available. For example:

nix-env -i python37
nix-env -u '*'

will get you python3.10 installed.

Changing the pname affects nix-env users.

so they don't get updates for installed packages, because the name does not exist anymore? that would be indeed very bad.

with the current rules, that would happen every time a package switches from stable to unstable release and the other way around

and i'm not sure if nix would update a package if the version changes from 0.5 to 2021-01-05

this one time i didn't question the existing rules, but it looks like i should 😬

so, how can we get to a consistent state from here. nixpkgs is a mess

Until we have no consent how to do this I don't think we should change it. I am still for changing nix to fit this usecase.

i think this change was needed for repology. not sure if it is still needed @jtojnar

Repology currently uses value nix-env parses from name. So the only way to make it work is to make -unstable suffix of version. See #100833

When a revision is used instead of a reference or explicit release, it not always means it corresponds to an unstable version. The unstable' addition to the name is to indicate the unstable variant, as @jonringer points out, to differentiate from the stable version. Sometimes, we need to fetch a revision because using patches is not workable. Changing the pname affects nix-env users.

nix-env only uses name so it does not matter for it whether unstable is a suffix of pname or prefix of version. The reason why we started moving unstable to version is to be able to get project name programmatically and because it makes more sense when we interpret pname as project name.

so they don't get updates for installed packages, because the name does not exist anymore? that would be indeed very bad.

with the current rules, that would happen every time a package switches from stable to unstable release and the other way around

Yes, that is correct.

and i'm not sure if nix would update a package if the version changes from 0.5 to 2021-01-05

If parseDrvName returns the same name component then it should. 2012-01-05 is lexicographically greater than 0.5, AFAICT. The other way around probably will not work, unless user explicitly specifies update policy flag #100833 (comment)

this one time i didn't question the existing rules, but it looks like i should grimacing

so, how can we get to a consistent state from here. nixpkgs is a mess

We need policy change along the lines of #100833 (comment) and #100833 (comment). That works for both nix-env and repology (if unstable is part of pname there is another, stable package with pname matching the project name). Of course, that requires consensus, which requires patience.

Result of nixpkgs-review pr 110442 1

OK, pausing the work on this until we have consensus how it should be.

[682 built (32 failed), 6845 copied (42866.2 MiB), 23537.2 MiB DL]
error: creating directory '/tmp/nix-build-perl5.32.0-Compress-Raw-Zlib-2.096.drv-0': No space left on device

FYI: There are already 120 packages following this convention.

[davidak@gaming:~/code/nixpkgs]$ egrep -R "pname.+=.+unstable" pkgs/ | wc -l
120

After this change it's 479 (unstable packages).

If I had to make a rule for unstable releases, it would be <previous stable release>post-<version control system>.<short version control reference>

E.g.

version = "unstable-2020-01-09";
....
   rev = "77ca3aab2ae....";

would be

version = "0.1.0post-git.77ca3aab"
...
  rev = "77ca3aab2ae...";

unfortunate, builtins.parseDrvName deliminates on a number, so we can't just do <pkg>-git.789392

nix-repl> builtins.parseDrvName "name-1"
{ name = "name"; version = "1"; }

nix-repl> builtins.parseDrvName "pkgname-ab42"
{ name = "pkgname-ab42"; version = ""; }

nix-repl> builtins.parseDrvName "pkgname-git.3242"
{ name = "pkgname-git.3242"; version = ""; }

nix-repl> builtins.parseDrvName "pkgname-1git.3242"
{ name = "pkgname"; version = "1git.3242"; }

another option would be, to do the current paradigm, but just drop unstable altogether

nix-repl> builtins.parseDrvName "pkgname-2020-01-22"
{ name = "pkgname"; version = "2020-01-22"; }

this is what vimPlugins does already, as vim plugins usually just track the latest default branch

nix-repl> vimPlugins.vim-css-color.name
"vimplugin-vim-css-color-2020-08-16"

nix-repl> vimPlugins.vim-css-color.pname
"vim-css-color"

nix-repl> vimPlugins.vim-css-color.version
"2020-08-16"

I would not consider having parseDrvName results match pname and version necessary. Ideally, we would deprecate this function in favour of lib.getName and lib.getVersion.

We need unstable or some other tag so that repology can filter it out easily.

What exactly is the problem we are trying to solve by including unstable? I see the point about repology, but there are ways around that.

How about this.

Last released version followed by a release date such as 0.5.4.20200108

Pros:

1. no messing around with the pname
2. upgrades continue to work as expected for all cases
3. it's clear to a human reader that this is a snapshot
4. parseDrv and friends continue to work as normal

Cons:

1. Not easy to determine in a programmatic manner that this isn't a formally released version

For repology, we would then presumably show as being up to date as we are > latest official release. As soon as version 0.5.5 is released we are back to showing out of date as expected.

In case a project hasn't made a formal release ever, we could still do 0.0.0.releasedate

It is not about appearing up to date on repology. Repology uses version data from distros as a proxy for project versions so if we used version that is greater than the latest stable version and cannot be filtered out, it would actually mark other distros as outdated. That could only lead to nixpkgs being blacklisted as a whole.

Also note that your proposed format is actually used by some projects for their official releases so we still would not be able to distinguish VCS snapshots from official releases. (first one I found by greping)

I think we need a new variable which tells you that the version we use is unreleased and picked from master.

I think that would be even harder to push through – we would still need to teach nix-env and Repology about it and I do not see that very likely given that unstable tag already does the same job quite well.

I absolutely agree with @peterhoeg but propose following Debians model of extended version numbers and using a format along the lines of 0.5.4+nix.20200108 with 0.0.0+nix.20200108 being used for packages without upstream releases.

I think it would be very unfortunate if the notion of package name and version differs between Nix and Nixpkgs. It is already difficult enough to understand how things interact in the Nix ecosystem and moving away from

getName = s: (builtins.parseDrvName s).name
getVersion = s: (builtins.parseDrvName s).version

is simply confounding when the documentation for builtins.parseDrvName says

Split the string s into a package name and version.

Edit: I would be willing to participate in, but not drive, an RFC for a change in this direction since it's been a pain point for many years.

propose following Debians model of extended version numbers and using a format along the lines of 0.5.4+nix.20200108 with 0.0.0+nix.20200108 being used for packages without upstream releases.

That would require manually reviewing hundreds of packages and researching if they have a release at all and after which version number we are currently.

I don't think that is feasible. We only have the date right now and we can shuffle that together with the package name and unstable or any other string how we want. Changing pname when fetching unstable versions is not an option because pname is used in thousands of places to refer to the package name. This leaves us with two options: unstable or any other string before or after the date in the version number. Either way needs a fix in the builtin to fully function if I remember correctly.

Related: #68518

Repology uses version data from distros as a proxy for project versions so if we used version that is greater than the latest stable version and cannot be filtered out, it would actually mark other distros as outdated.

I believe a version is only considered valid if more than one distro has the same version. Otherwise it's first considered a "unique" version.

However, I think in principle we should still try to avoid polluting repology with bad information.

I believe a version is only considered valid if more than one distro has the same version. Otherwise it's first considered a "unique" version.

Not so much. higan is outdated in almost all distros (because they changed the build system radically), but the new version was taken from... Wikidata.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/brainstorming-for-rfc-pname-and-version/12873/1

I marked this as stale due to inactivity. → More info

Closing due to huge conflicts.