hackage2nix reproducibility

[roberth]

I've tried to run hackage2nix in order to test a change I made to the yaml file in Nixpkgs. I didn't make it through. I'll summarize my experience.

1. I used git add worktree and git checkout --detach instead of git clone nixpkgs to speed it up. Didn't work because update-nixpkgs.sh pulls in the nixpkgs worktree.
2. I had to add cabal, ghc, zlib and openssl to my shell before invoking update-nixpkgs.sh
3. Still, cabal failed with

   $ ./update-nixpkgs.sh 
   <command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory)
   cabal: Failed to build cabal2nix-2.15.0 (which is required by exe:hackage2nix
   from cabal2nix-2.15.0).
   

Proposed solution

I think the script can be nixified. I suggest adding the following to Nixpkgs:

• pin files for
  • cabal2nix repo revision
  • all-cabal-hashes repo revision
• a port of update-nixpkgs.sh, limited to generation
  • using the pins
  • no assumption about the caller's environment (nix-shell shebang or similar)
  • no git logic, just generation
• a script to update the pins and call the codegen script
• assuming the code generation is now pure, a derivation that tests whether the generated code is up to date, to prevent hand-editing and ensure reproducibility

This will let anyone regenerate the package set in a reproducible way. This also makes #219 trivial. Just mention the pin files in a comment.

Did I miss something that makes the above not work?

[peti]

https://www.youtube.com/watch?v=qX0mgtSm360 has very detailed instructions how to run hackage2nix. Maybe that is helpful? Once you have actually built the executable correctly, you'll find that it's actually pretty easy to run.

[roberth]

That's really cool that you've put it in a video. Video is a great format for explaining things.

When I tried running the update script, I followed the Setup and Run steps in the hackage2nix README. My goal was to test a configuration change, not hacking on hackage2nix or anything like that. Even without my "proposed solution" I don't think that it should take more than a little shell script invocation.

If my intention was to do more work on hackage2nix etc, I'd probably have found the video.

[peti]

I believe I can close this issue now. Do you agree? Or do you feel like your suggestion hasn't been fully resolved or addressed yet?

[roberth]

The hackage2nix readme does not work if you don't also follow the steps from the video. I think the instructions in the readme itself should be minimal but correct. Minimal because the video does a good job explaining all the subtleties, correct because otherwise people run into trouble like me.

You have spent significant effort on the current workflow and I understand if you're not motivated to change it again. Perhaps you don't want people to regenerate the package set in a single command without setup? Anyway, that's up to you as a maintainer.

[peti]

The hackage2nix readme does not work if you don't also follow the steps from the video.

Would you mind making a specific suggestion how to improve the README? I would very much like it to describe the process correctly, so if you could offer concrete advice -- or a PR? -- then that would be very useful.

You have spent significant effort on the current workflow and I understand if you're not motivated to change it again.

What makes you say that? If the workflow can be improved, then I am all for it! I just don't see what improvements you would suggest, specifically. What would you like to change?

[nh2]

Going through this as well myself now, I think I start to understand what @roberth is asking.

A common use case seems to be that somebody wants to "just" do a minor change to configuration-hackage2nix.yaml, and then render the results out into hackage-packages.nix using hackage2nix.

But there are some obstacles to it:

• The default workflow relies on tooling outside nixpkgs. The tooling itself is not version-pinned, and a user has to learn multiple stps in order to run it.
  • It would be better if we could have a script in pkgs/development/haskell-modules, that drops you in a shell that has cabal2nix (and its hackage2nix executable) from that same nixpkgs. Then one could run ./generate-hackage-packages.sh straight from that directory, without having to setup anything.
• The update-nixpkgs.sh in cabal2nix does various things that one may not need/want, such as git reset -q --hard inside nixpkgs. That is a bit impractical for the use case of quickly testing a local change.
  • W could perhaps make a ./generate-hackage-packages.sh process the configuration-hackage2nix.yaml right next to it, without any git operations.

[roberth]

The steps in Nixpkgs to regenerate the packages have been reduced to essentially two steps, which is close enough for me.

My notes for a quick test with updated hackage, distilled from the more complete pkgs/development/haskell-modules/HACKING.md (or its permalink)

Test newly uploaded release

Check that all-cabal-hashes is up to date with your upload. Run:

./maintainers/scripts/haskell/update-hackage.sh
./maintainers/scripts/haskell/regenerate-hackage-packages.sh
nix-build -A haskellPackages.foo

[sternenseemann]

Pending tasks are:

• Document at least the regenerate-hackage-packages.sh script in the nixpkgs manual
• Remove the legacy hackage2nix scripts from this repository (I think they now only serve to confuse users)