hackage2nix: Always print extraVersions

[alexarice]

See discussion in NixOS/nixpkgs#90143

In short, I would like to be able to pin nixpkgs's agdaPackages to version 2.6.1. I had hoped that adding Agda == 2.6.1 to extra-packages in the config would cause a Agda_2_6_1 attribute to be generated, though this is not the case with current hackage2nix. This PR changes this so that a fixed version attribute is made, even if this is identical to the default version.

I have built this and ran it and it creates this diff on nixpkgs master

diff --git a/pkgs/development/haskell-modules/hackage-packages.nix b/pkgs/development/haskell-modules/hackage-packages.nix
index 609090b610c..9904897657a 100644
--- a/pkgs/development/haskell-modules/hackage-packages.nix
+++ b/pkgs/development/haskell-modules/hackage-packages.nix
@@ -825,6 +825,40 @@ self: {
        maintainers = with stdenv.lib.maintainers; [ abbradar ];
      }) {inherit (pkgs) emacs;};
 
+  "Agda_2_6_1" = callPackage
+    ({ mkDerivation, aeson, alex, array, async, base, binary
+     , blaze-html, boxes, bytestring, Cabal, containers, data-hash
+     , deepseq, directory, edit-distance, emacs, equivalence, exceptions
+     , filepath, geniplate-mirror, ghc-compact, gitrev, happy, hashable
+     , hashtables, haskeline, ieee754, mtl, murmur-hash, pretty, process
+     , regex-tdfa, split, stm, strict, template-haskell, text, time
+     , transformers, unordered-containers, uri-encode, zlib
+     }:
+     mkDerivation {
+       pname = "Agda";
+       version = "2.6.1";
+       sha256 = "0af1nyyscdc4gr4l0k3ayq3rn8qxqkx1b7rh4mw023gkz1m433v7";
+       isLibrary = true;
+       isExecutable = true;
+       enableSeparateDataOutput = true;
+       setupHaskellDepends = [ base Cabal directory filepath process ];
+       libraryHaskellDepends = [
+         aeson array async base binary blaze-html boxes bytestring
+         containers data-hash deepseq directory edit-distance equivalence
+         exceptions filepath geniplate-mirror ghc-compact gitrev hashable
+         hashtables haskeline ieee754 mtl murmur-hash pretty process
+         regex-tdfa split stm strict template-haskell text time transformers
+         unordered-containers uri-encode zlib
+       ];
+       libraryToolDepends = [ alex happy ];
+       executableHaskellDepends = [ base directory filepath process ];
+       executableToolDepends = [ emacs ];
+       description = "A dependently typed functional programming language and proof assistant";
+       license = "unknown";
+       hydraPlatforms = stdenv.lib.platforms.none;
+       maintainers = with stdenv.lib.maintainers; [ abbradar ];
+     }) {inherit (pkgs) emacs;};
+
   "Agda-executable" = callPackage
     ({ mkDerivation, Agda, base }:
      mkDerivation {
@@ -29520,6 +29554,19 @@ self: {
        license = stdenv.lib.licenses.bsd3;
      }) {};
 
+  "ansi-terminal_0_10_3" = callPackage
+    ({ mkDerivation, base, colour }:
+     mkDerivation {
+       pname = "ansi-terminal";
+       version = "0.10.3";
+       sha256 = "0z5m6ljmdyjyzq0s08rjjdzdj1ry4fz2ni7xlxd86addvwr2wbps";
+       isLibrary = true;
+       isExecutable = true;
+       libraryHaskellDepends = [ base colour ];
+       description = "Simple ANSI terminal support, with Windows compatibility";
+       license = stdenv.lib.licenses.bsd3;
+     }) {};
+
   "ansi-terminal-game" = callPackage
     ({ mkDerivation, ansi-terminal, array, base, bytestring, cereal
      , clock, exceptions, hspec, linebreak, mintty, mtl, QuickCheck
@@ -114444,6 +114491,35 @@ self: {
        license = stdenv.lib.licenses.mit;
      }) {};
 
+  "haskell-lsp_0_22_0_0" = callPackage
+    ({ mkDerivation, aeson, async, attoparsec, base, bytestring
+     , containers, data-default, directory, filepath, hashable
+     , haskell-lsp-types, hslogger, hspec, hspec-discover, lens, mtl
+     , network-uri, QuickCheck, quickcheck-instances, rope-utf16-splay
+     , sorted-list, stm, temporary, text, time, unordered-containers
+     }:
+     mkDerivation {
+       pname = "haskell-lsp";
+       version = "0.22.0.0";
+       sha256 = "0mh2b3dza633plxp370zhvml50kfx4szk4hrzmcfm6aij2di2l0w";
+       isLibrary = true;
+       isExecutable = true;
+       libraryHaskellDepends = [
+         aeson async attoparsec base bytestring containers data-default
+         directory filepath hashable haskell-lsp-types hslogger lens mtl
+         network-uri rope-utf16-splay sorted-list stm temporary text time
+         unordered-containers
+       ];
+       testHaskellDepends = [
+         aeson base bytestring containers data-default directory filepath
+         hashable hspec lens network-uri QuickCheck quickcheck-instances
+         rope-utf16-splay sorted-list stm text unordered-containers
+       ];
+       testToolDepends = [ hspec-discover ];
+       description = "Haskell library for the Microsoft Language Server Protocol";
+       license = stdenv.lib.licenses.mit;
+     }) {};
+
   "haskell-lsp-client" = callPackage
     ({ mkDerivation, aeson, base, bytestring, containers, directory
      , haskell-lsp, lens, process, text, unix
@@ -114483,6 +114559,23 @@ self: {
        license = stdenv.lib.licenses.mit;
      }) {};
 
+  "haskell-lsp-types_0_22_0_0" = callPackage
+    ({ mkDerivation, aeson, base, binary, bytestring, data-default
+     , deepseq, filepath, hashable, lens, network-uri, scientific, text
+     , unordered-containers
+     }:
+     mkDerivation {
+       pname = "haskell-lsp-types";
+       version = "0.22.0.0";
+       sha256 = "05475d5rwkmsh50q18lans7zzd34jhfdpg80m7aijg829dkphskm";
+       libraryHaskellDepends = [
+         aeson base binary bytestring data-default deepseq filepath hashable
+         lens network-uri scientific text unordered-containers
+       ];
+       description = "Haskell library for the Microsoft Language Server Protocol, data types";
+       license = stdenv.lib.licenses.mit;
+     }) {};
+
   "haskell-menu" = callPackage
     ({ mkDerivation, base, containers }:
      mkDerivation {

cc @cdepillabout as you may be interested

I apologise in advance for any haskell style errors

[nh2]

See discussion in NixOS/nixpkgs#90143

In short, I would like to be able to pin nixpkgs's agdaPackages to version 2.6.1.

We just reviewed this in @peti's Haskell twitch stream, but neither from here nor from the linked thread we understand why this is the right thing to do or desirable.

Usually nixpkgs tries to avoid pinning Haskell packages as much as possible, so that the update procedure is automatic and does not depend on a person bumping versions. Pins are usually added only to work around failure cases, not as the default.

The only automatic pin that nixpkgs does is to pin Stackage versions.

So far we think that if Agda wants to provide "stable versions" of its ecosystem that compile with each other, this should go into Stackage instead of nixpkgs. This reduces nixpkgs maintenance efforts, and also means that all Linux distributions get well-working Agda versions, not only nixpkgs.

Please let us know if we missed something!

[alexarice]

How would pinning a version in stackage work? I assume this would need to be done upstream. I am not quite sure how this generates problems with maintance, as wouldn't a pinned stackage version require as much maintainership here as a pinned nix version here? If this is not the way to try and do this then the linked pr above should likely be reverted.

I'm basically just trying to replicate the structure of coqModules with the only difference that Agda is written in haskell instead of ocaml. I'm not sure there are any more similar packages to compare this to. The problem is that a new version will likely not be backwards compatible and make all the packages useless.

[cdepillabout]

How would pinning a version in stackage work? I assume this would need to be done upstream. I am not quite sure how this generates problems with maintance, as wouldn't a pinned stackage version require as much maintainership here as a pinned nix version here? If this is not the way to try and do this then the linked pr above should likely be reverted.

Pinning a version in stackage would basically mean getting Agda (and all it's dependencies) into stackage.

This describes how to get a package into stackage: https://github.com/commercialhaskell/stackage#add-your-package

I assume this would need to be done upstream.

Anyone is able to get a package into stackage, but you will need to send a PR to the stackage repo as described in the steps above. You don't necessarily have to involve the Agda upstream.

If Agda relies on libraries that aren't in stackage nightly, you'll either have to send a PR to the Agda repo removing them (or bumping versions), or send a PR to the stackage repo adding them as well.

I am not quite sure how this generates problems with maintance, as wouldn't a pinned stackage version require as much maintainership here as a pinned nix version here?

peti runs a script regularly that pulls in the latest stackage lts version and locks all packages to those versions. We know that those packages are all able to be compiled together (aside from the various fixes needed specifically for nixpkgs).

This usually reduces the maintenance burden for us, and also makes it so that other distros are able to pull in a given Haskell package much easier. Like nh2 is saying, this is often better for the community.

[alexarice]

There is a line https://github.com/commercialhaskell/stackage/blob/e96f08afccf1112598816a47cc9c52b4600cead6/build-constraints.yaml#L2347 here however I guess the < 0 is saying not to build it? Also are you suggesting adding multiple versions of the same package to stackage. I think I'm a bit out of my depth here

[cdepillabout]

@alexarice I think that < 0 is done whenever a package is not able to be compiled in stackage nightly. I think this usually happens because of version constraints.

I suggest you follow the directions on the stackage repo and first make sure that Agda is able to built with stackage nightly. If so, then you should probably open a PR removing the < 0, and possibly pinging the maintainer in that build-constraints.yaml file so they know you have fixed it.

If you have trouble, I suggest opening an issue on the stackage repo to ask for help from the stackage maintainers.

[alexarice]

How does this allow multiple versions to be built?

[cdepillabout]

@alexarice No, there is only one version of any given package at a time in Stackage.

[alexarice]

Just to check, the issue with pinning an old version here is that eventually the dependencies will update versions and could break the pinned version, and the pinned version would only be fixable by pinning more packages.

Edit: And even keeping an extra version around for a short amount of time isn't ideal as it would require manual changes to clean up old versions etc.