Gearing up for a cabal-install-1.16.0 release

Simon Marlow marlowsd at gmail.com
Tue Oct 9 12:11:45 CEST 2012


On 01/10/2012 09:26, Duncan Coutts 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.

Forgive me if I'm being stupid, but why can't the feature be implemented
entirely on the server? That is, when the dependencies are updated by
some as-yet-unspecified mechanism on the server, a complete new version
of the package is generated and added to the index. A new tarball would
be generated on the server, by replacing the .cabal file in the previous
tarball. The behaviour would be exactly as if a new version had been
uploaded, but it is all done by Hackage, using some pre-agreed version
numbering policy.

This would eliminate the problems of having invisible metadata floating
around, and having 'cabal unpack' doing clever magic behind your back.
The index would remain a pure function of the set of tarballs.

Cheers,
	Simon




More information about the cabal-devel mailing list