Cabal woe

Tue Jul 9 13:35:52 UTC 2024

>
> I think Simon has a point. I really do not enjoy creating a new throwaway
> project for every small reproducer I want to test.

My (clearly faulty) mental model is this.

   - I have a particular stage2 compiler, say $(GHC).  Maybe built in my
   build tree, maybe installed.
   - If I say `$(GHC) -package primitive`, it right says "I don't know
   about primitiver"
   - I expect to be able to say `cabal install primitive
   --with-compiler=$(GHC)`, to extend my $(GHC) with the package `primitive`.
   - Thereafter I expect `$(GHC) -package primitive` to work -- after all,
   I have extended GHC to  know about it.

If I'm in a cabal project then these installed-by-default packages
shouldn't make any difference; cabal will control everything.

I'm sure it used to be like this, but something has changed, and I'm not
sure why.

Clearly my model of cabal is faulty, but I don't know how to get an
accurate one.  Is there a writeup I can read?  e.g. What is the
"environments" file?  Why does it fail to find Prelude?

Would it be possible to support the simple story above, as well?

Simon

On Tue, 9 Jul 2024 at 13:23, Sebastian Graf <sgraf1337 at gmail.com> wrote:

> Hi Simon, Hi Matt,
>
> I think Simon has a point. I really do not enjoy creating a new throwaway
> project for every small reproducer I want to test.
> A cabal project means that I can't simply pass `-fforce-recomp
> -ddump-simpl -O` to a GHC invocation, for example.
> Instead I have to create a cabal file and remember all the fields that
> need to be set. (Or <enter> myself through a perceived 30 step wizard with
> `cabal new`, only to find that I have to open the file anyway to tweak
> build-depends...)
>
> Stupid as it may be, that subconsciously really affects my willingness to
> tackle an issue.
>
> Presumably this can be solved through some amount of automation/scripting.
> Perhaps it would be enough to share these scripts in a prominent location,
> for example the Wiki.
> Alternatively, I think I would enjoy something like `nix-shell -p`, where
> I can just fire up a temporary shell with all the deps in a locally visible
> package db. That way I could keep calling `ghc` directly.
>
> (Not that I suffer *much* from this issue at the moment anyway.)
>
> Sebastian
>
> Am Di., 9. Juli 2024 um 11:21 Uhr schrieb Matthew Pickering <
> matthewtpickering at gmail.com>:
>
>> `cabal install --lib` is very hard to use properly. I would advise
>> against it.
>>
>> It is much easier to create a simple cabal project and use normal
>> cabal build commands. I packaged things in a repo for you.
>>
>> https://github.com/mpickering/t25064
>>
>> ```
>> cabal build -w ghc-9.6.2 (fails)
>> cabal build -w /path/to/devel/compiler (fails with error message)
>> ```
>>
>> Matt
>>
>> On Tue, Jul 9, 2024 at 9:58 AM Simon Peyton Jones
>> <simon.peytonjones at gmail.com> wrote:
>> >
>> > Friends
>> >
>> > I'm trying to repro #25064 with my development build of GHC.  The test
>> case depends on packages `primitive` and `hashtables`.  So I try this (see
>> below).
>> >
>> > Alas, apparently after the `cabal install`, it can't find Prelude.
>> >
>> > What should I do?  I tried removing the "environments" file, whatever
>> that is, which then meant it could find Prelude -- but the libraries were
>> no longer installed.
>> >
>> > I lack a decent model of what is going on with installing packages for
>> my development builds.   Is there a write up anywhere?
>> >
>> > Thanks
>> >
>> > Simon
>> >
>> >
>> > bash$ cabal install --lib hashtables primitive --with-compiler
>> $HOME/code/HEAD/$s2
>> > Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.10.1.0
>> supports
>> > 'ghc' version < 9.8): /home/simonpj/code/HEAD/_build/stage1/bin/ghc is
>> version
>> > 9.11.20240517
>> > Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.10.1.0
>> supports
>> > 'ghc' version < 9.8): /home/simonpj/code/HEAD/_build/stage1/bin/ghc is
>> version
>> > 9.11.20240517
>> > Resolving dependencies...
>> > bash$  ~/code/HEAD/$s2 -c T25064.hs
>> > Loaded package environment from
>> > T25064.hs:1:8: error: [ ]8;;
>> https://errors.haskell.org/messages/GHC-87110 \GHC-87110 ]8;; \]
>> >     Could not load module ‘Prelude’.
>> >     It is a member of the hidden package ‘base-4.20.0.0’.
>> >     Use -v to see a list of the files searched for.
>> >   |
>> > 1 | module Bug where
>> >   |        ^^^
>> >
>> > bash$ rm
>> /home/simonpj/.ghc/x86_64-linux-9.11.20240517/environments/default
>> > bash$ ~/code/HEAD/$s2 -c T25064.hs
>> > T25064.hs:3:1: error: [ ]8;;
>> https://errors.haskell.org/messages/GHC-61948 \GHC-61948 ]8;; \]
>> >     Could not find module ‘Control.Monad.Primitive’.
>> >     Perhaps you meant Control.Monad.Writer (from mtl-2.3.1)
>> >     Use -v to see a list of the files searched for.
>> >   |
>> > 3 | import Control.Monad.Primitive
>> >   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >
>> > T25064.hs:4:1: error: [ ]8;;
>> https://errors.haskell.org/messages/GHC-87110 \GHC-87110 ]8;; \]
>> >     Could not find module ‘Data.HashTable.ST.Basic’.
>> >     Use -v to see a list of the files searched for.
>> >   |
>> > 4 | import qualified Data.HashTable.ST.Basic as H
>> >   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240709/6b905b8a/attachment.html>