Dear Simon, I do not know the answer to your question, but I do know a few workarounds using cabal that may or may not be helpful. Cabal lets you do this: $ cabal repl -b hspec -w ~/code/HEAD-22/_build/stage1/bin/ghc this creates a fake project with "hspec" as the list of dependencies, and starts a ghci session there. (You could also write something like `cabal repl -b 'hspec ==2.11.17, HUnit >= 1.6'` -- it's really a list of constraints.) Naturally, this doesn't work if you want to compile a file instead of opening ghci. One can work around this as follows (but see the warning below): $ cabal repl -b hspec -w ~/code/HEAD-22/_build/stage1/bin/ghc --repl-option=-fobject-code --repl-option=Foo.hs which does open ghci, but it compiles Foo.hs to an object file, which may sufficient for your use case. Warning: it seems that -fobject-code breaks the illusion that the fake project doesn't actually exist, as a `dist-newstyle` tree is created in the current directory, which you may need to clean up afterwards. Note: I used --repl-option twice instead of --repl-options (mind the S) once to allow spaces in Foo.hs. Another workaround which does allow you to avoid opening ghci but requires editing the test file, is to make it a "cabal script". [1] If I put the below (between the markers) in a file `test.hs`: ``` {- cabal: build-depends: base, hspec -} {- project: with-compiler: /path/to/some/ghc -} module M where x = 4 ``` and run: $ cabal build test.hs the thing is compiled to an object file, and I get an error from GHC that there was no Main module but there was a -o option so what did you want to do exactly. (If test.hs is a Main module, this works better, naturally). Apologies if this is not helpful, but perhaps at least one of these tricks was new to one of the readers of this list. - Tom [1]: https://cabal.readthedocs.io/en/stable/cabal-commands.html#cabal-run On 10/04/2026 09:22, Simon Peyton Jones via ghc-devs wrote:

Why you want to build and install a bunch of libraries? You most likely don't want to do that.

I think I really do.  Let's call my build #22   ghc-22 export ghc-22 $HOME/code/HEAD-22/_build/stage1/bin/ghc

Then on any one of dozens of 5-line tests, given in tickets, I can say

ghc-22 -c Foo.hs

and ghc-22 already knows about base, ghc-internal, text, containers etc built by and for ghc-22.  They are squirrelled away somewhere in $HOME/code/HEAD-22/_build

It's like "batteries included": I already have `base`

Now some has a test that needs `hspec`.  I'd like to add `hspec` to the batteries in $HOME/code/HEAD-22/_build, so that after that I can always say   ghc-22 -package hspec Foo.hs and away we go.

Yes I could make a cabal project for a 5-line test, but that's more keystrokes.  Is it difficult to just get it to treat `hspec` the same way that it treats `base` or `containers`?

I know this isn't the intended use-case for cabal; it's just the use-case I have.

Thanks

Simon

On Fri, 10 Apr 2026 at 05:01, Oleg Grenrus via ghc-devs wrote:

Why you want to build and install a bunch of libraries? You most likely don't want to do that.

If you want to play with particular GHC version, create an ordinary cabal package with dependencies you need, and point `cabal-install` to use your HOME/code/HEAD-22/_build/stage1/bin/ghc

There is nothing (noteworthy) special about `cabal repl -w $HOME/code/HEAD-22/_build/stage1/bin/ghc`; as long as `cabal-install` is concerned, it's just some GHC build.

- Oleg

On 4/8/26 17:43, Simon Peyton Jones via ghc-devs wrote:

...

Dear devs

I have thirty or so builds of GHC on my disk.  Sometimes I want to use one build to build and install (for that build alone) a bunch of libraries.  If I do    cabal install hspec  -w $HOME/code/HEAD-22/_build/stage1/bin/ghc then Cabal rightly warns me

Warning: The libraries were installed by creating a global GHC environment file at: /home/simonpj/.ghc/x86_64-linux-9.15.20260309/environments/default

The presence of such an environment file is likely to confuse or break other

tools because it changes GHC's behaviour: it changes the default package set in ghc and ghci from its normal value (which is "all boot libraries"). GHC environment files are little-used and often not tested for.

Question: how can I install the libraries in the build tree for $HOME/code/HEAD-22? After all, I think ghc-internal, base etc are all in that build-tree.  Surely hspec can be too?

But how?

Thanks!

Simon

_______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org

_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

_______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org

 why ghc-22 can know about `base`

...

Why you want to build and install a bunch of libraries? You most

Because these are part of global package database. And since a decade ago cabal-install treats global package database as immutable. And very likely if you modify package database in _build, hadrian might get very confused. Yes, the immutability of global package database might be inconvenient for the very few GHC hackers, but by making it practically impossible to modify that database saves a lot of people from (accidentally) messing their setups. likely don't want to do that.

I think I really do

I argue that if you don't really feel that you need to amend global package database of your "main" global/default GHC, then you don't need to amend the global package database of your WIP-GHC either. It might be the very case that you don't work on "ordinary" projects i.e. which use cabal as their build tool but are intended to be compiled with different GHC versions, so you don't feel at home using cabal-install, writing package & project definitions and changing to different GHC versions at will. But please trust me that the non-stateless workflow of cabal-install is really a lot better long term and actually allows you do more stuff Allow `cabal-install` manage (the local) package database for you.

All those see a bit complicated wrt

FWIW, I also think that the invocations Tom mentioned are a lot more complicated compared to writing minimal package definition   cabal-version: 3.0   name: my-test   version: 0   library     build-depends: base, hspec     exposed-modules: Foo.hs and `cabal build -w $HOME/code/HEAD-22/_build/.../ghc` and `cabal build -w ghc` to compare the behavior with stock GHC etc. There are those six or so lines of "boilerplate setup", but they actually do declare dependencies, so in case you have to return to this example later, or share it with someone, it's all there in "runnable" format. - Oleg On 4/10/26 22:09, Simon Peyton Jones via ghc-devs wrote:

Thank you.  All those see a bit complicated wrt   ghc-22 Foo.hs -package hspec

I am curious about why ghc-22 can know about `base` and `containter` (all safely tucked away in $HOME/code/HEAD-22/_build) but not about `hspec`.

Simon

On Fri, 10 Apr 2026 at 14:47, Tom Smeding via ghc-devs wrote:

Dear Simon,

I do not know the answer to your question, but I do know a few workarounds using cabal that may or may not be helpful.

Cabal lets you do this:

$ cabal repl -b hspec -w ~/code/HEAD-22/_build/stage1/bin/ghc

this creates a fake project with "hspec" as the list of dependencies, and starts a ghci session there. (You could also write something like `cabal repl -b 'hspec ==2.11.17, HUnit >= 1.6'` -- it's really a list of constraints.) Naturally, this doesn't work if you want to compile a file instead of opening ghci.

One can work around this as follows (but see the warning below):

$ cabal repl -b hspec -w ~/code/HEAD-22/_build/stage1/bin/ghc --repl-option=-fobject-code --repl-option=Foo.hs

which does open ghci, but it compiles Foo.hs to an object file, which may sufficient for your use case. Warning: it seems that -fobject-code breaks the illusion that the fake project doesn't actually exist, as a `dist-newstyle` tree is created in the current directory, which you may need to clean up afterwards. Note: I used --repl-option twice instead of --repl-options (mind the S) once to allow spaces in Foo.hs.

Another workaround which does allow you to avoid opening ghci but requires editing the test file, is to make it a "cabal script". [1] If I put the below (between the markers) in a file `test.hs`:

``` {- cabal: build-depends: base, hspec -} {- project: with-compiler: /path/to/some/ghc -} module M where x = 4 ```

and run: $ cabal build test.hs the thing is compiled to an object file, and I get an error from GHC that there was no Main module but there was a -o option so what did you want to do exactly. (If test.hs is a Main module, this works better, naturally).

Apologies if this is not helpful, but perhaps at least one of these tricks was new to one of the readers of this list.

- Tom

[1]: https://cabal.readthedocs.io/en/stable/cabal-commands.html#cabal-run

On 10/04/2026 09:22, Simon Peyton Jones via ghc-devs wrote:

...

Why you want to build and install a bunch of libraries? You most likely don't want to do that.

I think I really do.  Let's call my build #22   ghc-22   export ghc-22 $HOME/code/HEAD-22/_build/stage1/bin/ghc

Then on any one of dozens of 5-line tests, given in tickets, I can say

ghc-22 -c Foo.hs

and ghc-22 already knows about base, ghc-internal, text, containers etc built by and for ghc-22.  They are squirrelled away somewhere in $HOME/code/HEAD-22/_build

It's like "batteries included": I already have `base`

Now some has a test that needs `hspec`.  I'd like to add `hspec` to the batteries in $HOME/code/HEAD-22/_build, so that after that I can always say     ghc-22 -package hspec Foo.hs and away we go.

Yes I could make a cabal project for a 5-line test, but that's more keystrokes.  Is it difficult to just get it to treat `hspec` the same way that it treats `base` or `containers`?

I know this isn't the intended use-case for cabal; it's just the use-case I have.

Thanks

Simon

On Fri, 10 Apr 2026 at 05:01, Oleg Grenrus via ghc-devs wrote:

Why you want to build and install a bunch of libraries? You most likely don't want to do that.

If you want to play with particular GHC version, create an ordinary cabal package with dependencies you need, and point `cabal-install` to use your HOME/code/HEAD-22/_build/stage1/bin/ghc

There is nothing (noteworthy) special about `cabal repl  -w $HOME/code/HEAD-22/_build/stage1/bin/ghc`; as long as `cabal-install` is concerned, it's just some GHC build.

- Oleg

On 4/8/26 17:43, Simon Peyton Jones via ghc-devs wrote:

...

Dear devs

I have thirty or so builds of GHC on my disk. Sometimes I want to use one build to build and install (for that build alone) a bunch of libraries.  If I do    cabal install hspec  -w $HOME/code/HEAD-22/_build/stage1/bin/ghc then Cabal rightly warns me

Warning: The libraries were installed by creating a global GHC environment file at: /home/simonpj/.ghc/x86_64-linux-9.15.20260309/environments/default

The presence of such an environment file is likely to confuse or break other

tools because it changes GHC's behaviour: it changes the default package set in ghc and ghci from its normal value (which is "all boot libraries"). GHC environment files are little-used and often not tested for.

Question: how can I install the libraries in the build tree for $HOME/code/HEAD-22? After all, I think ghc-internal, base etc are all in that build-tree.  Surely hspec can be too?

But how?

Thanks!

Simon

_______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org

_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

_______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org

_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

_______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org

The manual should be the best place. However, the questions you ask, i.e. - "what is a package database" - "how does writing a minimal package definition make a sandbox that protects you from X and Y" are wrong questions. As user of cabal-install you should not worry about package databases (which are really a GHC concept) nor really think of sandboxes (as there aren't any in the direct meaning). Instead, in my opinion, the right (and only) question you should ask is "how to write .cabal package definition" which is answered in https://cabal.readthedocs.io/en/stable/how-to-package-haskell-code.html I personally don't like `cabal init` wizard, but it's ok if you are not too familiar with .cabal files. - Oleg On 4/15/26 13:26, Simon Peyton Jones wrote:

Thanks Oleg.

Where is the best place to read about cabal's mental model of package databases (global and local), project files. etc? Just basic things like "what is a package database" and "how does writing a minimal package definition make a sandbox that protects you from X and Y".

I had a look at https://cabal.readthedocs.io/en/stable/cabal-context.html which is a good start, but doesn't explain enough concepts.

Is there anything else I should look at?

Thanks

Simon

On Tue, 14 Apr 2026 at 17:31, Oleg Grenrus via ghc-devs wrote:

> why ghc-22 can know about `base`

Because these are part of global package database. And since a decade ago cabal-install treats global package database as immutable. And very likely if you modify package database in _build, hadrian might get very confused.

Yes, the immutability of global package database might be inconvenient for the very few GHC hackers, but by making it practically impossible to modify that database saves a lot of people from (accidentally) messing their setups.

>> Why you want to build and install a bunch of libraries? You most likely don't want to do that.

> I think I really do

I argue that if you don't really feel that you need to amend global package database of your "main" global/default GHC, then you don't need to amend the global package database of your WIP-GHC either. It might be the very case that you don't work on "ordinary" projects i.e. which use cabal as their build tool but are intended to be compiled with different GHC versions, so you don't feel at home using cabal-install, writing package & project definitions and changing to different GHC versions at will. But please trust me that the non-stateless workflow of cabal-install is really a lot better long term and actually allows you do more stuff

Allow `cabal-install` manage (the local) package database for you.

> All those see a bit complicated wrt

FWIW, I also think that the invocations Tom mentioned are a lot more complicated compared to writing minimal package definition

  cabal-version: 3.0   name: my-test   version: 0

  library     build-depends: base, hspec     exposed-modules: Foo.hs

and `cabal build -w $HOME/code/HEAD-22/_build/.../ghc` and `cabal build -w ghc` to compare the behavior with stock GHC etc.

There are those six or so lines of "boilerplate setup", but they actually do declare dependencies, so in case you have to return to this example later, or share it with someone, it's all there in "runnable" format.

- Oleg

On 4/10/26 22:09, Simon Peyton Jones via ghc-devs wrote:

...

Thank you.  All those see a bit complicated wrt     ghc-22 Foo.hs -package hspec

I am curious about why ghc-22 can know about `base` and `containter` (all safely tucked away in $HOME/code/HEAD-22/_build) but not about `hspec`.

Simon

On Fri, 10 Apr 2026 at 14:47, Tom Smeding via ghc-devs wrote:

Dear Simon,

I do not know the answer to your question, but I do know a few workarounds using cabal that may or may not be helpful.

Cabal lets you do this:

$ cabal repl -b hspec -w ~/code/HEAD-22/_build/stage1/bin/ghc

this creates a fake project with "hspec" as the list of dependencies, and starts a ghci session there. (You could also write something like `cabal repl -b 'hspec ==2.11.17, HUnit >= 1.6'` -- it's really a list of constraints.) Naturally, this doesn't work if you want to compile a file instead of opening ghci.

One can work around this as follows (but see the warning below):

$ cabal repl -b hspec -w ~/code/HEAD-22/_build/stage1/bin/ghc --repl-option=-fobject-code --repl-option=Foo.hs

which does open ghci, but it compiles Foo.hs to an object file, which may sufficient for your use case. Warning: it seems that -fobject-code breaks the illusion that the fake project doesn't actually exist, as a `dist-newstyle` tree is created in the current directory, which you may need to clean up afterwards. Note: I used --repl-option twice instead of --repl-options (mind the S) once to allow spaces in Foo.hs.

Another workaround which does allow you to avoid opening ghci but requires editing the test file, is to make it a "cabal script". [1] If I put the below (between the markers) in a file `test.hs`:

``` {- cabal: build-depends: base, hspec -} {- project: with-compiler: /path/to/some/ghc -} module M where x = 4 ```

and run: $ cabal build test.hs the thing is compiled to an object file, and I get an error from GHC that there was no Main module but there was a -o option so what did you want to do exactly. (If test.hs is a Main module, this works better, naturally).

Apologies if this is not helpful, but perhaps at least one of these tricks was new to one of the readers of this list.

- Tom

[1]: https://cabal.readthedocs.io/en/stable/cabal-commands.html#cabal-run

On 10/04/2026 09:22, Simon Peyton Jones via ghc-devs wrote:

...

Why you want to build and install a bunch of libraries? You most likely don't want to do that.

I think I really do.  Let's call my build #22   ghc-22   export ghc-22 $HOME/code/HEAD-22/_build/stage1/bin/ghc

Then on any one of dozens of 5-line tests, given in tickets, I can say

ghc-22 -c Foo.hs

and ghc-22 already knows about base, ghc-internal, text, containers etc built by and for ghc-22. They are squirrelled away somewhere in $HOME/code/HEAD-22/_build

It's like "batteries included": I already have `base`

Now some has a test that needs `hspec`.  I'd like to add `hspec` to the batteries in $HOME/code/HEAD-22/_build, so that after that I can always say ghc-22 -package hspec Foo.hs and away we go.

Yes I could make a cabal project for a 5-line test, but that's more keystrokes.  Is it difficult to just get it to treat `hspec` the same way that it treats `base` or `containers`?

I know this isn't the intended use-case for cabal; it's just the use-case I have.

Thanks

Simon

On Fri, 10 Apr 2026 at 05:01, Oleg Grenrus via ghc-devs wrote:

Why you want to build and install a bunch of libraries? You most likely don't want to do that.

If you want to play with particular GHC version, create an ordinary cabal package with dependencies you need, and point `cabal-install` to use your HOME/code/HEAD-22/_build/stage1/bin/ghc

There is nothing (noteworthy) special about `cabal repl  -w $HOME/code/HEAD-22/_build/stage1/bin/ghc`; as long as `cabal-install` is concerned, it's just some GHC build.

- Oleg

On 4/8/26 17:43, Simon Peyton Jones via ghc-devs wrote:

...

Dear devs

I have thirty or so builds of GHC on my disk.  Sometimes I want to use one build to build and install (for that build alone) a bunch of libraries.  If I do  cabal install hspec  -w $HOME/code/HEAD-22/_build/stage1/bin/ghc then Cabal rightly warns me

Warning: The libraries were installed by creating a global GHC environment file at: /home/simonpj/.ghc/x86_64-linux-9.15.20260309/environments/default

The presence of such an environment file is likely to confuse or break other

tools because it changes GHC's behaviour: it changes the default package set in ghc and ghci from its normal value (which is "all boot libraries"). GHC environment files are little-used and often not tested for.

Question: how can I install the libraries in the build tree for $HOME/code/HEAD-22? After all, I think ghc-internal, base etc are all in that build-tree.  Surely hspec can be too?

But how?

Thanks!

Simon

_______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org

_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

_______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org

_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

_______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org

_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org