Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
add maintainer scripts for haskell package generation #86699
Motivation for this change
Currently, the Nix file responsible for the Haskell package set is created from mutable state by a script run by @peti that makes commits to nixpkgs, making it hard to reproduce. This means that changes in the package set cannot easily be evaluated by users other than them, and the script that executes a regular task which needs to be applied to nixpkgs is hard to use and maintained outside of it.
@hyperfekt Thanks for working on this.
There are frequently contributors that ask if there is an easy way to regenerate the hackage package set, normally for testing changes they have made.
Here is the most recent: #86659 (comment)
I think having something like this in nixpkgs would be nice, mostly for the people like the above link.
I have some specific questions about this PR though, so I'll ask those questions inline.
Introduces a script that can be used to update the Nix expressions for the Haskell package set. In service of that, also - introduces cabal2nix-latest, which pins the hackage2nix version used - changes all-cabal-hashes to use fetchFromGitHub - adds update-hackage.sh & update-cabal2nix-latest.sh maintainer scripts
Let me put it this way:
It has been shown in the past that, while certainly entirely possible, the hurdle of generating the Haskell package set anew with the current process is one that many do not clear, and there is no good reason for it being remotely this burdensome, requiring every user to replicate a frankly (for Nix standards) arcane setup; when with the power of Nix it can be as simple as executing a single command. I also recall hearing about people who have gained the understanding of how to do it still finding it too troublesome to perform.
I have chosen to include these scripts in nixpkgs because
Your declaration of not maintaining them I take absolutely no issue with (I'm happy to do that), and your not wanting to use them I have accepted. I don't think either of these are reasons not to include them. Again, they are not for you.
I do however need your minimal support in pinning the versions used to generate
I'm not sure I see the harm in adding this sort of pinning to the scripts you use, so maybe you could enlighten me about the problems it brings instead of outright rejecting it without giving a reason.
PS: I very much appreciate your intent to make the package generation more efficient through the direct use of Cabal's tarballs. But until that is implemented I think these scripts are very useful, and even when implemented we would want (slimmer, simpler) scripts as well as pinning in order to not increase the friction to more than necessary.
@peti I have thought about this a bit more. There is one reason, why we maybe want more reproducibility than we have right now.
But now if everyone where to generate the
So I think the case can be made, that pinning the hackage version to generate
So I think the over all goal should be: a) Make the regeneration of the nix file easy and b) make the regeneration with the same hackage version easy.
Now, I have said nothing about what the best way to achieve that would be. But this PR supplies a solution that works right now. Another approach would be to have hackage2nix print the hackage snapshot to the top of the nix file (I know it‘s written in the commit message but that is harder to extract for tooling) and then have some tool (probably in the hackage2nix repo) that can pull that exact hackage version, be it a git-repo or a tarball …
Just to avoid misunderstandings: we have reproducibility.
I have tried to verify your claim. I remain unconvinced as of now:
It is likely that the issue is my mistake. But I needed 30 minutes to get to that point. I think the Haskell tooling in nixpkgs is great. I am really amazed by it. But I think it can be made easier to use.