There's this devilish thing where an initial install of cabal goes to
/usr/bin/cabal, but then a subsequent update
$ cabal install cabal-install
puts things in my ~/.cabal/bin/
Once I adjusted my PATH to go to ~/.cabal/bin/cabal first, then
cabal -z install --lib string-conversions
works with the -z. And now everything works accordingly. My /usr/bin/cabal
was version 3.0...
On Tue, Jun 29, 2021 at 10:40 PM Viktor Dukhovni
On Tue, Jun 29, 2021 at 10:18:47PM -0500, Galaxy Being wrote:
Sorry, but this didn't work for me. First,
$ cabal -z install --lib string-conversions cabal: unrecognized 'install' option `-z'
You must have a materially older version of cabal-install than I do. The "-z" option makes "cabal" ignore any local ".cabal" or "cabal.project" files, and operate in the "global" project.
From "cabal install --help":
... -z --ignore-project Ignore local project configuration ...
If I previously wrote "cabal -z install ...", the more strictly correct syntax would probably be "cabal install -z ...", perhaps your version of cabal supports the latter (but quite possibly neither).
$ cabal repl -z
:set -package string-conversions <no location info>: error: Could not load module ‘Data.String.Conversions’ It is a member of the hidden package ‘string-conversions-0.4.0.1’. Perhaps you need to add ‘string-conversions’ to the build-depends in your .cabal file.
Something is missing from the above. I see no attempt to load the module, and yet an error about failure to load it. If "cabal repl" did accept the "-z" option,
$ stack install string-conversions
then
$ stack ghci --package string-conversions
[...]
*But*, now I am able to follow your cabal way and it does work.
So this is very confusing for a beginner. But happy ending this time. Any lessons I can learn from this? For example, why was this so difficult?
It is tricky because cabal operates in a sanboxed mode by default, and because GHC and GHCi don't by default have any knowledge of cabal's package store. The Haskell tool chain is somewhat fragmented, but IIRC there are plans afoot to reduce some of the friction.
I use Cabal 3.4, and it does what I need. Others use stack which meets their needs. GHC is agnostic, and ghci mostly knows just about the packages bundled with GHC, except when cabal or stack create GHC "environment" files that specify the package-db locations which GHC is then able to use.
Someone else who understands the space better may be able to give a more detailed answer, and perhaps share any plans to improve toolchain integration.
-- Viktor. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf@gmail.com