Haskell packages in nixpkgs are often outdated or hang behind, e.g. hledger and git-annex and overriding them to get an up to date version is unreliable and prone to fail. However there exist prebuilt, statically-linked, standalone release binaries for these two in particular, so one can put them in a derivation, here’s mine:
Both seem to work fine for me.
Would something like this fit into nixpkgs? Or do we not like packaging binaries?
Why package the binaries in Nixpkgs when you could just bump the existing derivation?
It probably doesn’t make much sense to package the binary if you have the source available, there might be a few edges cases where it is required but those are probably rare.
as I wrote here. Have you tried it? If you get lucky, it works, then at some point it doesn’t anymore, super unreliable and I don’t like that. I want a way to use the latest version - who doesn’t? - and repackaging the upstream release binaries does that.
Repackaging upstream binaries is also generally prone to issues, even to more sneaky ones I’d say. You end up running with somewhat different versions of dependencies than it was built and tested with, etc.
As a git-annex user ignorant of Haskell, the way Haskell packages are handled in nixpkgs seems very different to how other applications are.
Is there some place where I can learn about that in addition to looking at the nix files?
I know at least about this one:
https://nixos.org/manual/nixpkgs/unstable/#haskell
but perhaps a better place to ask such stuff is
What I meant is to update the derivation in Nixpkgs not just an overlay.
Fix it for everybody.
Besides that you could try to use the package from unstable.
This can have some side effects as well however.
But it’s only one release behind if you can live with that.
I found mightyiam’s podcast episode about Haskell insightful: Full Time Nix | Horizon Haskell with Daniel Firth
The haskell packages are autogenerated, and making some application or library derive from the default of the stackage snapshot they used to autogenerate is not trivial. I tried to keep an updated version of hledger for a while in my own ledger-shell, but it was tedious and I had to touch the expression about every other week.
If I would have been in charge to keep it working for nixpkgs, I would not have been able to keep up…
I think something similar is true for other haskell based packages as well.
How that? They’re statically built self-contained binaries. I run the included test suites in the above derivations, everything works fine.
That’s a job for people that understand Haskell and nixpkgs’ auto-packaging of it. Mortals need a way to run the latest versions of these apps.
unstable also often wildly out of date. Neither Git annex not hledger are up to date in unstable, git annex 2 months behind, hledger half a year.
Ah, OK, I didn’t know that. For example hledger in nixpkgs is not static at all and depends on libraries from several packages.
Nixpkgs uses the version from the latest stackage snapshot if available. We are currently running GHC 9.8.4 hence hledger 1.40
nixpkgs hledger maintainer here. I find “wildly out of date” a bit dramatic, but I hear your desire for quicker releases.
As others explained the slow movement speed is caused by our process of tracking Stackage LTS and the very small maintainer count for haskellPackages (although that has recently improved a little.)
If I am being asked, I would vote against packaging static binaries in Nixpkgs for packages for which we have perfectly fine derivations to build from source. From my point of view maintaining a more up-to-date hledger would be more sustainable than regularly updating the binaries.
As I commented elsewhere I am open to exempting hledger from the stackage pin. Doing that in nixpkgs will probably be less work than doing it an override outside of nixpkgs. It’s likely to actually be nearly no effort if hledger keeps backwards compatibility with current stackage LTS.
I would start by adding a line like -e '/ hledger/d' (no space after it so that we catch all hledger-* packages) in line ~73 of maintainers/scripts/haskell/update-stackage.sh. Then run maintainers/scripts/haskell/regenerate-hackage-packages.sh and try to build hledger.
I would be very happy to help with all efforts/PRs in this direction (really!). I am reachable here, on GitHub and in #haskell:nixos.org.
Sadly we lack a comprehensive guide, but I think the important points are covered in the nixpkgs manual which @vcunat linked, indeed. More of our workflow is explained in haskellPackages: Stackage 23.19 -> 23.21 by sternenseemann · Pull Request #404362 · NixOS/nixpkgs · GitHub and the links from there.
If packaging the binary works for you then you found a solution for yourself?
It just doesn’t make much sense for the whole Nixpkgs.
Git-annex is only one release behind on unstable from what I can see.
Hledger seems to lag a bit more.
Thank you for maintaining it 
I understand now that it’s an LTS thing.
Yep, just wanted to share it here if anyone might be in need of running latest versions of hledger and git-annex declaratively. When I started using NixOS and had no clue of anyhing, I would’ve loved to find these two derivations somewhere.
It doesn’t matter how many versions it’s behind, it’s the fact that there is no reliable (as in: rock solid with only bumped src in overrideAttrs, no fiddling with dependencies) way to use the latest version. git annex for example has been pumping out game changing new features frequently and even one version behind can be unworkable in situations.
I see such workarounds are not desired in nixpkgs, so I won’t push for it and I will just use the release binaries for now.
Thanks for your opinions.
In fact we’ve already been asking about this in 2022, but there seemed to be little interest: RFC: Provide latest versions of some Haskell executables at the top level · Issue #190542 · NixOS/nixpkgs · GitHub. I’d be happy to see contributions on latest pandoc, hledger (we’ve had hledger_1_41 steadily maintained last year as I remember) etc. I’d just like people to commit to actually doing that so it doesn’t fall to the small (compared to the size of haskellPackages) core Haskell team solely. In principle, we’re also open to lift the Stackage bound completely (where feasible) or use the latest version for the version we expose at the top level of pkgs.
As a background, there are basically two/three ways in which haskell packages can be “out of date”: