Haskell development shells are not very useful

[ncfavier]

nix develop nixpkgs#haskellPackages.foo gives me a shell without cabal, and if I add cabal myself it fails most of the time because of a missing system dependency (pkg-config, zlib, ...).

cc @sternenseemann @cdepillabout @maralorn

[cdepillabout]

@ncfavier Maybe you could be more specific in what you're trying to do and what is failing?

Here's an example of using a development shell for a Haskell package:

$ nix develop .#haskellPackages.termonad.env
$ nix-shell -I nixpkgs=./. -p cabal-install
$ cabal get termonad-4.2.0.1
$ cd termonad-4.2.0.1/
$ cabal build

This works for me (and Termonad is somewhat of a complicated package to build, since it needs many system dependencies).

A couple things to note here:

• When jumping into a development shell for a Haskell package, you'll likely want to use haskellPackages.foo.env, not haskellPackages.foo.
• The development environment for a Haskell package doesn't pull in cabal-install, because cabal-install isn't a required dependency. You can build Haskell packages without cabal-install. Also, cabal-install is one of those Haskell dev tools that generally works with multiple compiler versions, so it is often safe to install cabal-install globally.
• In practice, almost no one uses haskellPackages.foo.env, but instead functions like haskellPackages.developPackage or haskellPackages.shellFor.

[sternenseemann]

The point is that the environment you are dropped into directly is not intended to be a development environment, it is the derivation's build environment and only useful for debugging issues in the derivation build process. That build process is relatively low level and explicit about package dbs it creates (it does create multiple ones, so that's why ghcWithPackages isn't used).

For development environment you want to avoid that, likely, so we provide a friendlier environment via env which uses ghcWithPackages internally. Whether cabal-install should be in there is a matter of taste, you can use a globally installed one with an impure shell FWIW. Extra tools like shellFor allow you to add it in a pure manner.

I think the confusion stems from the original “overloading” of nix-shell which was intended for debugging package environments, but then got (ab)used for dev environments fairly quickly. Haskell has separated the two use cases from the beginning in order to be able to more cleanly separate the build steps (Setup.hs, main build) of a Haskell package in the derivation build.

TL;DR: The Haskell infra distinguishes between the derivation environment shell and a development shell and this is good, actually.

I've added the documentation label since this is not explicitly stated in a good place atm, but iirc I added a note about this in my in draft nixpkgs manual section.

[ncfavier]

Thanks for writing such detailed answers to such an underspecified question! It seems like both foo.env and shellFor do what I want (use Nix for dependencies) and I can add cabal-install to the build inputs so this is good.

developPackage doesn't seem to use ghcWithPackages so it still runs into missing pkg-config stuff when trying to build a package depending on e.g. gnuidn.

Agreed that there's no bug here, just needs better documentation.

[maralorn]

I guess that makes this a duplicate of #121403. :D