[Haskell-cafe] Using Data.String.Conversions
borgauf at gmail.com
Wed Jun 30 04:37:01 UTC 2021
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 <ietf-dane at dukhovni.org>
> 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
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> Only members subscribed via the mailman list are allowed to post.
Grand Marais, MN, USA
borgauf at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe