[Haskell-cafe] Using Data.String.Conversions

Galaxy Being 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>
wrote:

> 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 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210629/db3d4358/attachment.html>


More information about the Haskell-Cafe mailing list