Why is `nixpkgs.haskellPackages.time` null?

I try running the following in nix-repl:

nix-repl> pkgs = import <nixpkgs> {}
nix-repl> pkgs.haskellPackages.time
null

The same seems to be true for some other packages (such as containers and unix), and for different compiler versions. I would expect a derivation for a Haskell package there, as is the case for other packages like servant or conduit.

Does anyone know why this is? Just curious!

Those packages are shipped as a part of GHC. They still exist as attributes in haskellPackages so that the output of cabal2nix doesn’t have to know which packages are shipped in GHC.

3 Likes

I appreciate it, thank you so much!

I was thrown off by this too, and it seems an awful lot like a hack. Why was it done like this? Shouldn’t the fix have been in cabal2nix instead? There should be a way for cabal2nix to source this information from elsewhere, no?

I’m not entirely sure why it was done like this originally, but the current design allows cabal2nix to be mostly unaware of the GHC version that will be used to build the resulting derivation (which is important, because Nixpkgs allows multiple GHC versions to be used build the same underlying Haskell package derivation).

It also allows passing newer versions of the boot packages from Hackage (overwriting the default null values with actual packages) and having everything “mostly work”.

The current design seems more-or-less reasonable to me, although I agree with you that it is somewhat surprising when you first see it (especially if you’re not aware of how GHC boot packages work).

I’m not sure I understand what you’re suggesting. What would the fix look like in cabal2nix? And what information would it be sourcing from where?

While the current Haskell infrastructure in Nixpkgs works reasonably well (at least for some things), it is certainly not the be-all-end-all of build systems. There are a bunch of ways it could be fundamentally different. If you have some ideas of how a radically different architecture would look like, I’d be interested in hearing about it.

I don’t necessarily want to argue with this, there is quite a lot of code in the Nix ecosystem that seems an awful lot like a hack :slight_smile: