Gearing up for a cabal-install-1.16.0 release

[Duncan Coutts]

On 27 September 2012 15:44, Johan Tibell <johan.tibell at gmail.com> wrote:
> Hi all,
>
> There's been a long time since we had a cabal-install release and
> there are a lot of bug fixes in the repo we need to get out there.
>
> After discussing with Duncan we agreed that the cabal-install release
> should depend on the already released Cabal-1.16.0 package. I've
> created a new branch, cabal-install-1.16.0, for making the
> cabal-install-1.16.0 release. The branch was made from the point in
> the history where Cabal-1.16 was released. There were some patches on
> the cabal-1.16 branch that never made it into the Cabal-1.16 release.
> If there are any commits on the cabal-1.16 branch that you think
> should definitely be in cabal-install-1.16.0, please let me know and I
> will try to cherry-pick them. Here's the list of commits:

I mentioned I'd written a feature to update the .cabal file we use
when building with the same one as is in the package archive index.
I've now pushed that to the head branch. I think it would be good to
have on the 1.16 branch and included in the cabal-install release.

For context, as you know there's been a lot of discussion about
dependency version bounds and if we should use conservative or
optimistic bounds. Something that we've been thinking about for a
while that would help here is if we could adjust the dependencies
after a release.

For example if you used conservative bounds on a dependency and later
on a new version of that dependency is released, and it so happens
that you were lucky this time and your package does still build and
work with the new version. It'd be nice if you (or some other helper
monkey) could just adjust the version constraints to reflect reality.

Or the other way around, if you were using optimisitic bounds and a
new version of a dep is released and you were unlucky and it now
fails, then again we can tighten the version bounds.

Being able to do this relies on both editing on the server, and for
the client to actually use the updated .cabal file. So this patch
provides the client side part of the feature. The server side already
works (we've actually made quite a few edits to .cabal files on
hackage post-release) but the UI for it will improve significantly in
the new server which we expect to go live during the lifetime of this
next cabal-install release. So getting the feature in now would be a
real help to everyone (and ideally, most users will never notice).

The patches in question are below, they'll need to be merged into the
1.16 branch but I don't expect any problems there.

commit b7565f941b2dd5d61a77e46826fd256358505de7
Author: Duncan Coutts <duncan at community.haskell.org>
Date:   Sat Sep 29 01:41:31 2012 +0100

    Extend the unpack command for the .cabal file updating

    By default, "cabal unpack blah" will also update the .cabal file with
    the one from the index, so it's consistent with what you get via
    cabal install. Also added a --pristine flag so you can get the original
    tarball without the updated .cabal file.

commit b92cbb046feb20be6b656752b25d12a2f26abd42
Author: Duncan Coutts <duncan at community.haskell.org>
Date:   Sat Sep 29 01:34:58 2012 +0100

    On install, update the .cabal file with the one from the index

    This allows us to make minor changes to packages after they have been
    released, without changing the package .tar.gz file. We already keep
    the .cabal file outsite the package in the index and use it for
    dependency planning. This already lets us do fixes such as making
    dependency constraints tighter. Currently we cannot make dep
    constraints more relaxed however, since the original .cabal file is
    the one used when we get to the actual configure step.

    So with this change, we now use the updated .cabal file for the
    configure and build too. So there's more fixes we can do post-release.
    In particlar, in combination with easier editing on hackage, this
    should help us address the problems around the PVP and open or closed
    version constraints. It should allow a system of conservative upper
    bounds, but allow editing them when new versions of deps are released
    and we find that they happen to work fine.

Duncan