Why is cabal install foo --lib frowned upon?

Learn
#21

You should just call cabal install base some-package some-other-package some-other-package --lib --package-env=some-env-file to populate the whole env file at once, if possible. (and in general always use the --lib flag to populate an env file. without it, you’re instead installing executables).

#22

This:

Note that --package-env=some-env-file creates ~/.ghc/x86_64-linux-9.4.7/environments/some-env-file, which you can refer by name or by full path.

❯ ghci -package-env some-env-file
Loaded package environment from /home/andrea/.ghc/x86_64-linux-9.4.7/environments/some-env-file
GHCi, version 9.4.7: https://www.haskell.org/ghc/  :? for help

Also you have to include base because of a bug fixed only recently.

2 Likes
#23

I personally still find this somewhat smelly; i.e, with some package updates it turned out I ended up with a case wherein a direct ghc call resulted in a rather bizarre error:

https://paste.tomsmeding.com/yErx5YI1

Or, in other words, ghc was unable to manage different ABI-ed Vectors, and saw it as different types (explanation courtesy IRC / Geekosaur).

But to be explicit, I’m not encouraging the use of --lib, only the use of cabal install base --lib to generate a package environment file so that :set -package foo is viable from within a directly called ghci, and also, to get ghc to be able to directly compile.

Thank you so much for clarifying that the main issue with --lib, at least currently, is the global namespace pollution on GHC and GHCI, though, and that cabal hell has been mostly remedied.

1 Like