Gearing up for a cabal-install-1.16.0 release

[Conrad Parker]

On 1 October 2012 16:26, Duncan Coutts <duncan.coutts at googlemail.com> wrote:
> On 1 October 2012 04:21, Johan Tibell <johan.tibell at gmail.com> wrote:
>> Hi,
>>
>> I don't want to hold up the release on this issue if it needs more
>> discussion. I'd like to make another Cabal/cabal-install release
>> before end of the year (probably around GHC's release timeline), to
>> include the sandbox stuff once done. Would it be OK to wait until then
>> with these two patches?
>
> I think these specific patches do not need discussion now, here's why:
> the feature comes in two parts, server and client, the bulk of the
> feature is the server side part which is not implemented yet. There's
> plenty of time for more discussion of the feature in general before we
> start actually using it. But if we decide it's ok, then we have to
> wait even longer to start using it. We can deploy new server side code
> quickly, but not client side code. If we decide it's not ok, then we
> don't make use of the feature server-side and then we rip out the
> client code. So that's why I want to get the client code in now, in
> advance of the server side implementation.
>
> Also note, I have discussed this before with several people (and I
> think on this list too, a couple years back). So Bryan didn't see it,
> but it's not like I'm inventing this crazy idea from nowhere and
> forcing it on people. I'm very happy to discuss the details again, but
> that's independent of these two patches.

Please do; I think a 2 week discussion period would be appropriate
given that this is a surprise to most people here.

My understanding of this idea is:

  * some unspecified group of people with global authority on Hackage
can insert a new "x-hackage-version" line into existing .cabal files,
and modify dependency bounds
  * anyone parsing a .cabal file must now interpret x-hackage-version
as somehow appended to or overriding version (?)
  * using the "cabal unpack" tool will retrieve this modified .cabal file
  * using "wget" will retrieve a tarball containing the original .cabal file

I think this idea is the wrong way to go, as it mixes up
author-specified versioning info and distro-specified overrides in the
same mechanism. This will likely make it difficult for others to
package Haskell packages as the file contents retrieved no longer just
depend on the version requested. The retrieved file contents now
depend on the tool used for retrieval, and on the version of cabal
used for cabal unpack: distro developers who do not bootstrap with a
latest-version cabal will get the wget behaviour.

Conrad.