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

'--sandbox-config-file' changes where install looks for 'cabal.config' #1915

Open
mietek opened this Issue Jun 2, 2014 · 6 comments

Comments

Projects
None yet
6 participants
@mietek
Contributor

mietek commented Jun 2, 2014

Specifying the --sandbox-config-file option with a cabal install changes where cabal looks for cabal.config.

When using this option, cabal no longer looks for cabal.config in the current working directory, but instead looks in the directory of the specified sandbox config file.

To reproduce, start with ghc-7.8.2 and cabal-install-1.20.0.2. First, the expected behaviour:

~ $ mkdir /tmp/yakshavers-inc

~ $ cd /tmp/yakshavers-inc

yakshavers-inc $ cat >cabal.config <<EOF
constraints: utf8-string ==0.3.7
EOF

yakshavers-inc $ cat >yakshavers-inc.cabal <<EOF
name:           yakshavers-inc
version:        0.0
build-type:     Simple
cabal-version:  >=1.2

executable yakshavers-inc
  build-depends:  base, utf8-string
EOF

yakshavers-inc $ cabal sandbox init
Writing a default package environment file to
/private/tmp/yakshavers-inc/cabal.sandbox.config
Creating a new sandbox at /private/tmp/yakshavers-inc/.cabal-sandbox

yakshavers-inc $ cabal install --dry-run
Resolving dependencies...
In order, the following would be installed (use -v for more details):
utf8-string-0.3.7 (latest: 0.3.8)
yakshavers-inc-0.0

Now, the unexpected behaviour:

yakshavers-inc $ mkdir zoo

yakshavers-inc $ cd zoo

zoo $ cabal sandbox init
Writing a default package environment file to
/private/tmp/yakshavers-inc/zoo/cabal.sandbox.config
Creating a new sandbox at /private/tmp/yakshavers-inc/zoo/.cabal-sandbox

zoo $ cd ..

yakshavers-inc $ cabal --sandbox-config-file=zoo/cabal.sandbox.config install --dry-run
Resolving dependencies...
In order, the following would be installed (use -v for more details):
utf8-string-0.3.8
yakshavers-inc-0.0

Finally, to confirm:

yakshavers-inc $ cp cabal.config zoo

yakshavers-inc $ cabal --sandbox-config-file=zoo/cabal.sandbox.config install --dry-run
Resolving dependencies...
In order, the following would be installed (use -v for more details):
utf8-string-0.3.7 (latest: 0.3.8)
yakshavers-inc-0.0

@23Skidoo 23Skidoo added the sandbox label Jun 2, 2014

@23Skidoo

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Jun 2, 2014

Member

Yes, using the one in the current directory makes more sense.

Member

23Skidoo commented Jun 2, 2014

Yes, using the one in the current directory makes more sense.

@mietek mietek changed the title from --sandbox-config-file changes where install looks for cabal.config to '--sandbox-config-file' changes where install looks for 'cabal.config' Jun 26, 2014

@benarmston

This comment has been minimized.

Show comment
Hide comment
@benarmston

benarmston Dec 10, 2014

Contributor

I'm commenting here instead of on #1629 as that is closed. The cabal freeze command loads the cabal.config file twice. Once in Main.hs via D.C.Sandbox.loadConfigOrSandboxConfig, in order to load the saved configure flags. D.C.Sandbox.loadConfigOrSandboxConfig looks for the cabal.config file in either the current directory or the directory specified by --sandbox-config-file if it is given.

The second time that cabal.freeze loads cabal.config is when it writes out the constraints. It loads the cabal.config file in the current directory replaces any constraints with those calculated and writes the result back to the current directory.

Obviously, the difference in behaviour between the two uses is not correct. However, I'm not sure what the correct (desired) behaviour is. I did write a commit which removed the inconsistency by updating the cabal.config file in the --sandbox-config-file directory. However that was reverted.

I believe that every other command making use of cabal.config loads it through D.C.Sandbox.loadConfigOrSandboxConfig and so they all use the cabal.config in the --sandbox-config-file directory.

Obviously, we want all uses of how to load cabal.config to be consistent, so we can either:

  1. Change D.C.Sandbox.loadConfigOrSandboxConfig to always use the cabal.config file in the current directory (if any).
  2. Change cabal.freeze to write to the cabal.config file in the --sandbox-config-file directory.

What is the desired behaviour here?

Contributor

benarmston commented Dec 10, 2014

I'm commenting here instead of on #1629 as that is closed. The cabal freeze command loads the cabal.config file twice. Once in Main.hs via D.C.Sandbox.loadConfigOrSandboxConfig, in order to load the saved configure flags. D.C.Sandbox.loadConfigOrSandboxConfig looks for the cabal.config file in either the current directory or the directory specified by --sandbox-config-file if it is given.

The second time that cabal.freeze loads cabal.config is when it writes out the constraints. It loads the cabal.config file in the current directory replaces any constraints with those calculated and writes the result back to the current directory.

Obviously, the difference in behaviour between the two uses is not correct. However, I'm not sure what the correct (desired) behaviour is. I did write a commit which removed the inconsistency by updating the cabal.config file in the --sandbox-config-file directory. However that was reverted.

I believe that every other command making use of cabal.config loads it through D.C.Sandbox.loadConfigOrSandboxConfig and so they all use the cabal.config in the --sandbox-config-file directory.

Obviously, we want all uses of how to load cabal.config to be consistent, so we can either:

  1. Change D.C.Sandbox.loadConfigOrSandboxConfig to always use the cabal.config file in the current directory (if any).
  2. Change cabal.freeze to write to the cabal.config file in the --sandbox-config-file directory.

What is the desired behaviour here?

@mietek

This comment has been minimized.

Show comment
Hide comment
@mietek

mietek Dec 10, 2014

Contributor

We appear to be in agreement that the current behaviour of cabal --sandbox-config-file is surprising in general, and not just in the context of cabal freeze. Therefore, I suppose I am in favour of option 1.

Contributor

mietek commented Dec 10, 2014

We appear to be in agreement that the current behaviour of cabal --sandbox-config-file is surprising in general, and not just in the context of cabal freeze. Therefore, I suppose I am in favour of option 1.

@benarmston

This comment has been minimized.

Show comment
Hide comment
@benarmston

benarmston Dec 11, 2014

Contributor

@23Skidoo, @tibbe is changing existing behaviour in this way OK with you both?

Contributor

benarmston commented Dec 11, 2014

@23Skidoo, @tibbe is changing existing behaviour in this way OK with you both?

@23Skidoo

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Dec 11, 2014

Member

Yes, I think that --sandbox-config-file shouldn't affect the location of cabal.config.

Member

23Skidoo commented Dec 11, 2014

Yes, I think that --sandbox-config-file shouldn't affect the location of cabal.config.

@mietek

This comment has been minimized.

Show comment
Hide comment
@mietek

mietek Jan 24, 2015

Contributor

Halcyon includes a workaround for this issue.

Contributor

mietek commented Jan 24, 2015

Halcyon includes a workaround for this issue.

@ttuegel ttuegel added the type: bug label Apr 24, 2015

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

@23Skidoo 23Skidoo modified the milestones: cabal-install 1.24, cabal-install 1.26 Feb 21, 2016

@ezyang ezyang modified the milestone: cabal-install 2.0 Sep 6, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment