Opening up Cabal development

[Herbert Valerio Riedel]

On 2016-07-14 at 03:13:31 +0200, Edward Z. Yang wrote:

[...]

>> - I don’t break backwards compat for APIs without notice and
>> discussion, and don’t break backwards compat for any element of cabal
>> files without lots of discussion.

[...]

>    3. Can we build all Setup.hs scripts on Hackage?  This lets us know
>       which APIs in Cabal matter, and which ones we can change.
>       We'll need to establish base truth for this.

While we shouldn't break the API without a good reason, we added
custom-setup/setup-depends for the very reason to finally be able to
break Setup.hs. Now we can specify `Setup.hs`'s dependencies with
version constraints accurately, just like we already do with other
library dependencies via build-depends. Moreover, cabal-install has a
generous implicit upper bound on the Cabal lib version:


    -- The idea here is that at some point we will make significant
    -- breaking changes to the Cabal API that Setup.hs scripts use.
    -- So for old custom Setup scripts that do not specify explicit
    -- constraints, we constrain them to use a compatible Cabal version.
    -- The exact version where we'll make this API break has not yet been
    -- decided, so for the meantime we guess at 2.x.
    cabalCompatMaxVer = Version [2] []


So criteria 3 should be seen in the light of custom-setup/setup-depends.

Otoh, maybe we should collect and batch up all ideas (including
refactoring/aesthetic changes) to break the Cabal API for a big Cabal
2.0 rupture... :-)

> It is a travesty that this infrastructure does not exist; it may even
> be possible to do (1) and (3) on Travis, as they should not take too
> long to do.


So far, the criteria mentioned address mostly regressions.

What about changes extending the .cabal syntax? There's frequently
proposals to extend the features of .cabal files. I happen to propose
extensions myself from time to time (motivated by the issues I see as
Hackage Trustee).

Since changes to .cabal are effectively changes to the CABAL
specification future generations will have to cope with, I'd propose
that changes affecting or introducing new .cabal syntax/semantics should
go through a proposal process.

I.e. write up a specification/proposal outlining motivation (i.e. what
problem does this solve), specify what the changes are exactly (syntax &
semantics), what the consequences are, and so on.

Then we inevitably need some criteria to decide whether a proposal is
accepted and approved for implementation. This could be formally in the
hands of the core library committee together with the Hackage trustees
(since we do have quite some experience with .cabal files and care a lot
about the Hackage ecosystem).


-- hvr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20160714/bb96c3e8/attachment.sig>