Global Constraints for Cabal and also Release Plan?

[Gershom B]

Any more feedback on this? And also, do we have any plans for an
upcoming Cabal release?

Braindump here:

Once this lands and we have a cabal release, we can do a trial run of
a new minimal platform release. So I'm inclined to try to target a
cabal release for sooner than later if possible, to enable trying to
get the "minimal platform" proposal happening.

A "nice to have" in the future for the platform would be to help
address https://github.com/haskell/haskell-platform/issues/207

The proposal there would be to add an env variable (perhaps
CABAL_PATH_PREFIX) which, if it existed, would be added to the path
before running child processes (such as those kicked off by
build-type:configure). That way windows environments could provide the
Msys2 bin directory and those tools would then be made available to
the configure scripts, etc.

I haven't investigated adding this yet, but I don't think it would be
too much work.

If people are open to this, and especially if there were some
pointers, I'd be happy to look at this.

In any case, this is only a "nice to have" since it can be worked
around with an explicit "switcher script" prior to running
cabal-install.

Anyway, what are people's thoughts on A) getting the "global
constraints" PR added (https://github.com/haskell/cabal/pull/2820), B)
possibly adding the cabal-path-prefix logic, and C) a release
timetable with or without B so as to enable facilitate a minimal
platform release?

-g

On Fri, Sep 11, 2015 at 5:17 PM, Gershom B <gershomb at gmail.com> wrote:
> 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