Global Constraints for Cabal

[Gershom B]

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 <gershomb at 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