Skip to content

Cabal freeze does not clobber cabal.config #1629

Merged
merged 2 commits into from Dec 31, 2013

4 participants

@benarmston

This PR has the freeze command update the cabal.config file without clobbering all of its content, as wanted in #1615.

There are some limitations in the final approach which has been taken: 1) any comments in the file are removed; 2) the ordering of the configuration items may be changed; and 3) an extraneous field install-dirs is included. The ordering of the configuration items is stable, but in the case that a user has manually added new fields they may be changed.

I've taken a number of different approaches to get this working. I think that the final approach I've settled on is close to the correct one, but I'd appreciate it if someone could take a look and comment, and provide a suggestion on how to remove install-dirs from the included fields.

@23Skidoo
Haskell member

Nice, thanks. I'll take a look when I get home.

@benarmston

Rebased to remove a couple of redundant commits as requested.

@benarmston benarmston Replace hardcoded "" with use of getPkgEnvDir
This requires `getPkgEnvDir` to be exported from `D.Client.Sandbox`.
57bce8d
@tibbe tibbe merged commit 57bce8d into haskell:master Dec 31, 2013

1 check passed

Details default The Travis CI build passed
@tibbe
Haskell member
tibbe commented Dec 31, 2013

Merged. Sorry about the delay.

@23Skidoo

This causes a compile failure on my machine:

[74 of 76] Compiling Distribution.Client.Sandbox ( Distribution/Client/Sandbox.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Sandbox.o )

Distribution/Client/Sandbox.hs:35:5: Not in scope: `getPkgEnvDir'
@23Skidoo

I don't think that this is correct. We always search for cabal.config in the current directory even when the user has specified a different location for cabal.sandbox.config with --sandbox-config-file.

@23Skidoo
Haskell member

I'm reverting this commit for now.

@benarmston

Regarding the compilation failure, commit d8e1c31 moved getPkgEnvDir from a top-level function to a private function of loadConfigOrSandboxConfig and changed its type. I mention this as I wanted to understand why it was failing to compile for @23Skidoo but not for me or for Travis.

As this pull request remains closed but one of the commits on it has been reverted, I'm uncertain as to whether anything still needs to be done here. If so, let me know what and I'll see if I can find the time.

@23Skidoo
Haskell member
23Skidoo commented Jan 3, 2014

@benarmston As I said above, cabal.config is always loaded from the current directory, and not from the directory that cabal.sandbox.config resides in (the user can specify a different location for cabal.sandbox.config via the --sandbox-config-file option or the CABAL_SANDBOX_CONFIG environment variable). So IMO that commit was incorrect anyway.

@benarmston benarmston deleted the benarmston:cabal-freeze-does-not-clobber-cabal.config branch Jan 3, 2014
@mietek
mietek commented Dec 10, 2014

cabal.config is always loaded from the current directory, and not from the directory that cabal.sandbox.config resides in (the user can specify a different location for cabal.sandbox.config via the --sandbox-config-file option or the CABAL_SANDBOX_CONFIG environment variable).

While this describes what should happen, it does not describe what is happening, which is in fact, the opposite. See #1915 for details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.