sandbox-config's `package-db` path contains hardcoded GHC version #1935

Closed
hvr opened this Issue Jun 10, 2014 · 7 comments

Projects

None yet

4 participants

@hvr
Member
hvr commented Jun 10, 2014

When creating a new sandbox via cabal sandbox init, the auto-generated cabal.sandbox.config contains the following settings:

local-repo: /tmp/sb/.cabal-sandbox/packages
logs-dir: /tmp/sb/.cabal-sandbox/logs
world-file: /tmp/sb/.cabal-sandbox/world
user-install: False
package-db: /tmp/sb/.cabal-sandbox/x86_64-linux-ghc-7.8.2-packages.conf.d
build-summary: /tmp/sb/.cabal-sandbox/logs/build.log

install-dirs
  prefix: /tmp/sb/.cabal-sandbox
  bindir: $prefix/bin
  libdir: $prefix/lib
  libsubdir: $arch-$os-$compiler/$pkgid
  libexecdir: $prefix/libexec
  datadir: $prefix/share
  datasubdir: $arch-$os-$compiler/$pkgid
  docdir: $datadir/doc/$arch-$os-$compiler/$pkgid
  htmldir: $docdir/html
  haddockdir: $htmldir
  sysconfdir: $prefix/etc

The problematic line is

package-db: /tmp/sb/.cabal-sandbox/x86_64-linux-ghc-7.8.2-packages.conf.d

which makes it harder to share the same cabal.sandbox.config for multiple GHC versions. Ideally it would read like

package-db: /tmp/sb/.cabal-sandbox/$arch-$os-$compiler-packages.conf.d

Which, however, doesn't seem to be supported as cabal-install doesn't seem to support string-interpolation in the package-db field.

@hvr hvr added the sandbox label Jun 10, 2014
@23Skidoo
Member

which makes it harder to share the same cabal.sandbox.config for multiple GHC versions.

How is that a problem? cabal.sandbox.config is updated when you run cabal configure -w /path/to/ghc. To install dependencies, run cabal install -w /path/to/ghc --only-dependencies - it will also use the correct package DB.

@hvr
Member
hvr commented Jun 10, 2014

This is even more disturbing then if the cabal.sandbox.config file is rewritten each time a different ghc is picked up by cabal. Doesn't that cause problems when I run multiple cabal commands for different ghc versions in parallel?

@hvr
Member
hvr commented Jun 10, 2014

PS: cabal sandbox hc-pkg get's tripped up quite easily:

$ PATH=/opt/ghc/7.0.4/bin:$PATH cabal sandbox hc-pkg list --verbose
Using a sandbox located at /tmp/sb/.cabal-sandbox
/opt/ghc/7.0.4/bin/ghc-pkg --global --no-user-package-conf --package-conf=/tmp/sb/.cabal-sandbox/x86_64-linux-ghc-7.8.2-packages.conf.d list
ghc-pkg: too few bytes. Failed reading at byte position 1488
@23Skidoo
Member

cabal sandbox hc-pkg get's tripped up quite easily

Isn't this fixed in HEAD? hc-pkg should use the compiler the project was configured with.

Doesn't that cause problems when I run multiple cabal commands for different ghc versions in parallel?

That's not supported even when not taking sandboxes into account. E.g. if you try to run cabal build for two different compilers in the same directory, they will write over each other's temporary files and dist/setup-config. I recommend using two separate checkouts if you want to do that.

@hvr
Member
hvr commented Jun 10, 2014

Isn't this fixed in HEAD? hc-pkg should use the compiler the project was configured with.

Maybe that's the point, I don't regard the sandbox as associated with a package, I actually create a sandbox just as way to have an isolated environment separate from ${HOME].cabal/+${HOME}/.ghc. And then I start installing packages into that via cabal install <package-id|package-folder> as if I was operating against my "user global" ~/.cabal environment. Sometimes I place symlinks into several folders pointing to a common cabal.sandbox.config (and I wonder how that interacts with the config-rewriting).

However, I tried with HEAD, and it behaved the same wrt hc-pkg as shown above.

That's not supported even when not taking sandboxes into account. E.g. if you try to run cabal build for two different compilers in the same directory, they will write over each other's temporary files and dist/setup-config. I recommend using two separate checkouts if you want to do that.

Fwiw, I do that currently anyway exactly due to the dist/-issue you describe, however the $HOME/.cabal/ folder is shared (and configured in such a way that different compilers are isolated from each other). I'm just saying that the sandboxed .cabal

@23Skidoo
Member

Sometimes I place symlinks into several folders pointing to a common cabal.sandbox.config (and I wonder how that interacts with the config-rewriting).

You can also use cabal sandbox init --sandbox /path/to/shared-sandbox.

However, I tried with HEAD, and it behaved the same wrt hc-pkg as shown above.

OK, I'll investigate.

Fwiw, I do that currently anyway

Then I think it will work (sort of) with sandboxes as long as you don't mind that .o files and setup-config are overwritten.

@ttuegel ttuegel added this to the cabal-install-1.24 milestone Apr 24, 2015
@adamgundry
Contributor

I'm working on this at the London infrastructure hackathon.

@adamgundry adamgundry added a commit to adamgundry/cabal that referenced this issue Oct 11, 2015
@adamgundry adamgundry Use configured compiler for cabal sandbox hc-pkg
For most commands (e.g. `cabal install`), the `package-db` field in
`cabal.sandbox.config` is ignored, and the path is reconstructed
from the `prefix` and current compiler instead.  This is arguably
the right behaviour, because the right package DB depends on the
arch/compiler, so it doesn't make sense to specify only one.  This
commit makes `cabal sandbox hc-pkg` behave similarly, to avoid
invoking ghc-pkg on an incompatible package DB (fixes #1935).

Moreover, the compiler version to use is now picked up from the
most recently configured compiler, if any.  Otherwise, the global
default compiler is used, as before.
a25c166
@23Skidoo 23Skidoo closed this in #2859 Oct 12, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment