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 <gersh...@gmail.com> wrote: > 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 _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
