Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

find sandbox from an environment variable #1800

Closed
redneb opened this issue Apr 21, 2014 · 2 comments · Fixed by #2270
Closed

find sandbox from an environment variable #1800

redneb opened this issue Apr 21, 2014 · 2 comments · Fixed by #2270

Comments

@redneb
Copy link

redneb commented Apr 21, 2014

Currently, sandbox aware commands (such as cabal install) look for a sandbox in the current directory. I think it would be nice if there was an environment variable (e.g. CABAL_SANDBOX_PATH) that cabal examines in order to determine the path of the sandbox. This would allow a sandbox to be used while working in a directory different than the one where cabal sandbox init was issued from.

Here's an example scenario:

mkdir -p /tmp/dir1/dir2
cd /tmp/dir1
cabal sandbox init
cabal exec bash
cd dir2
cabal install somepackage

With cabal 1.20, the last command will install the package in ~/.cabal, despite the fact that we are inside a cabal exec environment.

hsenv handles the above situation nicely; once you enter an hsenv environment, you can issue a cabal install from any directory.

@tibbe
Copy link
Member

tibbe commented Apr 21, 2014

You can set CABAL_SANDBOX_CONFIG to point to a sandbox config located elsewhere. The config points to the package DB.

That being said, this looks like a bug in exec. It is supposed to set an environment variable that makes sure GHC uses the sandbox's package DB for installs.

/cc @benarmston

@benarmston
Copy link
Contributor

I can't reproduce the bug. Instead of installing cabal prints an error message and exits:

$ cabal install hlint
cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with
Cabal. Use the flag --package-db to specify a package database (it can be used
multiple times).

If I unset GHC_PACKAGE_PATH then I get the behaviour described in the bug: installs into the user database. If I then export CABAL_SANDBOX_CONFIG=/tmp/dir1/cabal.sandbox.config the install is into the sandbox.

So it would seem that we have two issues to fix here:

  1. Set the CABAL_SANDBOX_CONFIG variable when running cabal exec.
  2. Allow cabal to install into the sandbox when running under cabal exec. Perhaps instead of failing unconditionally if GHC_PACKAGE_PATH is set, we could check if CABAL_SANDBOX_CONFIG is also set and whether GHC_PACKAGE_PATH has the value that would be set for that sandbox.

benarmston added a commit to benarmston/cabal that referenced this issue Dec 13, 2014
Inside a cabal exec environment cabal should be configured to always use the
correct environment. When there is a sandbox this is addressed by setting the
CABAL_SANDBOX_CONFIG environment variable.

However GHC is configured to use the correct package database through setting
the GHC_PACKAGE_PATH environment variable to include the sandbox database. The
Cabal library previously refused to operate when GHC_PACKAGE_PATH is set in
order to avoid having a different view of the package databases to GHC.

In the case of a cabal exec environment being loaded for a cabal sandbox, it
is safe to allow the use of GHC_PACKAGE_PATH as it is being used to ensure
that GHC uses the same package database as cabal does.

A check is made that GHC_PACKAGE_PATH matches the value that cabal exec set it
to. If it does use of GHC through cabal is permitted.

Fixes haskell#1800
benarmston added a commit to benarmston/cabal that referenced this issue Dec 13, 2014
Inside a cabal exec environment cabal should be configured to always use the
correct environment. When there is a sandbox this is addressed by setting the
CABAL_SANDBOX_CONFIG environment variable.

However GHC is configured to use the correct package database through setting
the GHC_PACKAGE_PATH environment variable to include the sandbox database. The
Cabal library previously refused to operate when GHC_PACKAGE_PATH is set in
order to avoid having a different view of the package databases to GHC.

In the case of a cabal exec environment being loaded for a cabal sandbox, it
is safe to allow the use of GHC_PACKAGE_PATH as it is being used to ensure
that GHC uses the same package database as cabal does.

A check is made that GHC_PACKAGE_PATH matches the value that cabal exec set it
to. If it does use of GHC through cabal is permitted.

Fixes haskell#1800
benarmston added a commit to benarmston/cabal that referenced this issue Dec 18, 2014
Inside a cabal exec environment cabal should be configured to always use the
correct environment. When there is a sandbox this is addressed by setting the
CABAL_SANDBOX_CONFIG environment variable.

However GHC is configured to use the correct package database through setting
the GHC_PACKAGE_PATH environment variable to include the sandbox database. The
Cabal library previously refused to operate when GHC_PACKAGE_PATH is set in
order to avoid having a different view of the package databases to GHC.

In the case of a cabal exec environment being loaded for a cabal sandbox, it
is safe to allow the use of GHC_PACKAGE_PATH as it is being used to ensure
that GHC uses the same package database as cabal does.

A check is made that GHC_PACKAGE_PATH matches the value that cabal exec set it
to. If it does use of GHC through cabal is permitted.

Fixes haskell#1800
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants