[Haskell-cafe] Using Data.String.Conversions

[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.