Nixpkgs: Packages potentially breaking version parsing

[joepie91]

Issue description

According to the Nix source, the 'version' of a package is determined from the name as follows:

Parse a derivation name. The name part of a derivation name is everything up to but not including the first dash _not_ followed by a letter. The version part is the rest (excluding the separating dash).

... however, there are currently various packages that violate this pattern - for example, the various git- versions. One example is velox-git-2015-11-03, which should be parsed (according to the package author's intentions) as:

• Name: velox
• Version: git-2015-11-03

... but is instead parsed as:

• Name: velox-git
• Version: 2015-11-03

This problem has two consequences:

• Tools that attempt to parse the version of a package according to the rules described in the source, will get back the wrong package names/versions.
• _Removing_ the git- prefix for a package (whether to fix this issue, or because a package switches to 'real' versioned releases), might result in upgrades breaking - velox-git and velox would be considered to be different packages, and even if the git prefix were to be ignored internally, 2015-11-03 might still be considered a higher version than for example 1.2.

I'm not sure whether the solution here is in changing the parsing rules, or in changing the package names. For example - if a git prefix were not available for use, how would one package unversioned releases that come straight from Git?

(EDIT: I was just pointed at the existence of the package naming guidelines. Should this not be amended to call them rules rather than guidelines? As it stands, it's not obvious at all that there are technical consequences to not following them...)

Steps to reproduce

A full listing of affected packages due to the git prefix can be obtained as follows:

nix-env -qaP | grep '\-git\-'

... however, there may be other version prefixes that I am not aware of, that have the same issue.

Technical details

• System: 16.03.1242.c5cbda2 (Emu)
• Nix version: nix-env (Nix) 1.11.2
• Nixpkgs version: 6.03.1242.c5cbda2

[vcunat]

Should this not be amended to call them rules rather than guidelines?

The community on the whole seems to dislike hard rules. My view is that you need a good-enough reason to diverge from the "guidelines".

Note that not too long ago those guidelines were saying that you should put the "git" in there...

[joepie91]

I understand that and would normally agree with it - but in this case it's not just about "what should it look like", there are actual Nix internals relying on the package name format that is used. In this case, it's highly likely that using prefixes like git will break the upgrade process down the road.

I think this discussion is more akin to "should we allow comments in a JSON file" (which would break compatibility with parsers), than to "should we use newlines in a certain way".

[vcunat]

It acts as a package with a different name. Usually that seems fine to me.

[SN4T14]

Sure, it'll be fine until a package switches to a non-git version, and now suddenly the package is parsed as "velox" instead of "velox-git".

[vcunat]

Yes, it will break exactly when we try to "fix this issue" ;-)

[SN4T14]

It'll also break if you don't, the difference is technical debt. 5 years from now, guides can either say "oh by the way, some packages used to have a -git suffix but don't anymore" or "oh yeah if you ever have a git- prefix on your version string, that's stuck there". Either you break a few packages now, or you have a few packages _constantly_ breaking because of this.

[vcunat]

Constantly breaking?

[ericsagnes]

Another approach that sounded interesting was mentioned on the ML in this message.

Another solution is to abandon parsing of derivation name and include
"meta" to derivation. Then the name and version representations can be
included as meta.name and meta.version in whichever format is liked by
maintainer.

[joepie91]

@ericsagnes That seems like the most reasonable solution to me. We'd still have to work out a migration path for the existing packages, though - the version and/or package name 'jump' would still be there.

As a side-note, I'm currently writing a version parser for a Nix-related project that also correctly understands 'non-compliant' versions, and there are quite a few weird edge cases. I think that for these kind of purposes, specifying a meta.version would also help a lot.

[vcunat]

Some packages have already migrated to style where you can access foo.version (i.e. not in meta).

[FRidh]

From the manual:

If a package is not a release but a commit from a repository, then the version part of the name must be the date of that (fetched) commit. The date must be in "YYYY-MM-DD" format. Also append "unstable" to the name - e.g., "pkgname-unstable-2014-09-23".

so "pkgname-unstable-${version} with version = "YYYY-MM-DD". git, svn, etc. should be updated to this format.

With the functions for building Python packages I intend to make the version a parameter and let the functions put the name and version together, the reason being that if we automate the updating of packages further the version would be needed for selecting a different version of the package.

[Profpatsch]

Since this is an older discussion, I’m gonna close.