standardize multi-versioning suffix pattern in all-packages.nix

[ericsagnes]

Issue description

There are currently multiple different ways packages with multiple versions in all-packages.nix are named.

As this can be is confusing, it would be better to have a common pattern for versions suffixes.

Non exhaustive list:

packageVVV

• php55
• python33
• perl520
• ghc801
• erlangR18
• gcc49
• jdk7

package_V_V

• ruby_1_9
• scala_2_11
• ocaml_3_08_0
• guile_2_1

other patterns

• package-V_x: nodejs-6_x
• packageV_V: lua5_0

[FRidh]

In certain cases we have multiple versions because we want to support all those versions (e.g. Python interpreters) whereas in other cases we just need that version for a single or a couple of other packages. I've noticed that in python-packages.nix the format package_V_V is mostly used.

My preference is packageVV because it is shortest. If it is not in the guidelines I suggest adding this.

[globin]

I'd prefer package_V_V as it isn't ambiguous.

[FRidh]

@globin could you give an example of when another pattern would be ambigious?

Thinking a bit further about it. We also have suffixes like -unstable and. To stay in line with those we should maybe have package-VV (or package-V_V although I find that rather ugly and confusing) instead?

[globin]

Currently only theoretically, but if we have package_1, package_1_0, package_10 and package_10_0 that would be ambiguous. Apart from that I think it's easier to parse visually.

[dezgeg]

It's not even theoretical, we have spidermonkey_1_8_0rc1 and spidermonkey_185 currently (1.8.0rc1 and 185 respectively).

[the-kenny]

Another theoretical issue: rustc-1110. I'm voting against the short version, the ambiguity is very annoying.

[bjornfor]

I thought the manual said versioned attributes should be named foo-1-2, but I cannot find that reference anymore.

[edolstra]

I'm in favor of package_V_V. Note that in a few rare cases the package name includes part of the version, as in python3. Not sure if we should use python3_3 or python_3_3 (probably the former to be consistent with the python3 attribute).

[steveej]

Not sure if we should use python3_3 or python_3_3 (probably the former to be consistent with the python3 attribute).

python3 should not be a separate attribute. Instead, if multiple python versions can be chosen, they shall be stored in a set (dict, list, etc.) which can be used to determine the requested python version(s).

[bjornfor]

Ah, there it is [1]:

If there are multiple versions of a package, this should be reflected in the variable names in all-packages.nix, e.g. json-c-0-9 and json-c-0-11. If there is an obvious “default” version, make an attribute like json-c = json-c-0-9;

[1] https://nixos.org/nixpkgs/manual/#sec-package-naming

[vcunat]

We have it there but I think most cases don't follow it :-)

[FRidh]

Can we conclude that we go for package_V_V and that the manual should be updated to reflect this decision?

---

I actually think if the range of versions is small for a certain package that it should be fine to just use packageXX as well. E.g., in the case of Python we only expose 2.7 to 3.5. We don't include minor versions (e.g. 3.5.2). We do have 2 and 3, but I think to anyone using these packages it would be obvious what it would refer to.

With spidermonkey that's not really the case. Version numbers can be very different, so there it would be good to use a method which is unambiguous, like package_V_V.

However, while I think it's clear what the Python version digits imply, it might not be the case when we would support multiple versions of pypy. In that case you would have to refer to the Python language version, and the PyPy version, so you might get something like pypy3_5_5 to refer to version 5.5 of the Python 3 compatible PyPy interpreter.

[orivej]

It should be noted that in practice single version components are joined with the attribute differently than multiple version components: the former tend to have no separator and the latter tend to be separated by underscores. (Personally I also like this arrangement.) See the classification of python-packages.nix at #25261 (comment).

[ryantm]

I recently opened a similar topic on Discourse and came to a similar result on what seems to be the consensus here.

[Ekleog]

Closing as this should be a RFC, so that we could officially reach some kind of consensus on this question.

Feel free to reopen something against https://github.com/NixOS/rfcs/ , preferably pointing to this as prior discussion and summing the discussions here up :)

[roberth]

We should definitely change the docs to something else because it's out of touch by two orders of magnitude.

8 attributes satisfy [a-zA-Z]-[0-9]+(-[0-9]+)+ =. (nix-2-5)
689 attributes satisfy [a-zA-Z]_[0-9]+(_[0-9]+)+ = (nix_2_5)
17 attributes satisfy [a-zA-Z]-[0-9]+(_[0-9]+)+ = (nix-2_5)

[roberth]

The verson part is clear cut. The data speaks for itself; no need for an RFC. See comment above and PR: #156857