Use consistent package naming for HEAD.nix files #25631
Conversation
|
@rht, thanks for your PR! By analyzing the history of the files in this pull request, we identified @basvandijk, @Profpatsch and @jagajaga to be potential reviewers. |
So does the Coq compiler, and I had requested for the precise version taken from the git tags, but the disambiguation convention is to use commit date, which is better for scaling and automation. |
|
Yes, it’s not a good idea to make version tags consistent, especially not for very inconsistent and project-dependent topics like head versions. |
|
There are various head versions convention: projectname-numberofcommits-commithash (autogenerated in any git repo), numberofcommits (svn), ... (I forgot how hg does it, as it might include date). There are two ways to be consistent in head versions:
IMO, it should be either of the two options, but not a mixture of them. e: clarify the first option |
|
@rht the reason to this is because nix won't handle non numbers as a version. So |
|
@peti my fault. |
| @@ -12,7 +12,7 @@ let | |||
|
|
|||
| commonBuildInputs = [ ghc perl autoconf automake happy alex python3 ]; | |||
|
|
|||
| version = "8.1.20170106"; | |||
| version = "2017-01-06"; | |||
There was a problem hiding this comment.
Addressing @peti's objection: the git-generated version is ghc-8.3-start-421-g43a31683ac; the revision b4f2afe70ddbd0576b4eba3f82ba1ddc52e9b3bd doesn't have a tag, so I assume this revision was the HEAD commit of the time. And I see that "8.1.20170106" is a convention specific to ghc HEAD/unstable package rather than nix in general.
There was a problem hiding this comment.
For reference, here are the recent tags in ghc:
ghc-8.0.1-rc1
ghc-8.0.1-rc2
ghc-8.0.1-rc3
ghc-8.0.1-rc4
ghc-8.0.1-release
ghc-8.0.2-rc1
ghc-8.0.2-rc2
ghc-8.0.2-release
ghc-8.1-start
ghc-8.2.1-rc1
ghc-8.2.1-rc2
ghc-8.3-start
There was a problem hiding this comment.
@rht, I don't understand what you're getting at. Could you please revert these changes? If you have a better suggestion to be used for GHC HEAD version numbers, then by all means please make a suggestion in the form of a new PR, but the version numbers we have now are unsuitable, IMHO.
There was a problem hiding this comment.
The ghc HEAD version numbers as used by the upstream (generated by git, e.g. ghc-8.3-start-421-g43a31683ac) are not used at all here.
To explain once again, my change is based on
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"
There was a problem hiding this comment.
Please feel free to suggest better version numbers for the ghc and ghcjs expressions in a new PR. Then we can discuss that choice and reach a consensus. Meanwhile, I reverted your changes in a1b6c5f.
There was a problem hiding this comment.
noted: I will push the case specific to GHC and GHCjs in a new PR
Motivation for this change
This is a continuation of #21822 (comment). Naming is based on https://nixos.org/nixpkgs/manual/#sec-package-naming.
Things done
(nix.useSandbox on NixOS,
or option
build-use-sandboxinnix.confon non-NixOS)
nix-shell -p nox --run "nox-review wip"./result/bin/)