I've changed Freeze.hs to also respect this flag, and submitted a pull request:
https://github.com/haskell/cabal/pull/2820
--Gershom
On Thu, Sep 10, 2015 at 6:45 PM, Gershom B
Hi all. I've got a branch of cabal with a new feature: https://github.com/gbaz/cabal/tree/constraints-config
This lets you either pass `constraints-file` on the command line or in the ~/.cabal/config file.
The constraints-file serves as a "default" cabal.config file for freezes should one not be provided by a particular package.
Thus, a "minimal" platform can ship with a file that includes the platform constraints. Later, a user can simply download a new file for a new constraints set -- say lts -- and swap their config to point to that instead.
This makes both the platform in its new ideally-more-minimal guise and stackage play nicer together and with cabal, in a way that required minimal changes to cabal proper.
Ideally this or a relative can land soon to help enable the minimal platform plans (the work grew out of the discussion on: https://github.com/haskell/haskell-platform/issues/206)
There are two places where I wasn't quite sure what to do. In PackageEnvironment.hs, the tryLoadSandboxPackageEnvironmentFile doesn't check if this flag is set and handle that case. So this is when we are already in a sandbox and the question is if we should _also_ respect this flag, just as a sandbox also respects a cabal.config file directly in the directory. My gut says "don't respect it in sandboxes" but i'm not sure.
Additionally, the freezePackages function in Freeze.hs doesn't respect this flag. I'm not sure exactly what the full call chain here is yet, so haven't worked out the logic.
Anyway, thoughts?
--gershom