> On 14 Jul 2016, at 09:54, Edward Z. Yang wrote:
>
> Excerpts from Herbert Valerio Riedel's message of 2016-07-13 23:40:06 -0700:
>> 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).
>
> Why can't we release experimental changes to the Cabal specification?
> Neither setup-depends nor convenience libraries went through any formal
> proposal mechanism. If a feature is good people will start using it
> and we will have to continue supporting it. If a feature is bad/not
> useful we can yank it from the next release; anyone using an
> experimental feature like this isn't trying to maximize their
> Cabal compatibility anyway. And any change to the format with
> cabal-install can't parse is not going to be supportable via
> custom-setup anyway.
You gave a reason yourself:
- Can we parse all of Hackage?
With my industrial hat on, I don’t like the idea that I might need older Cabal,
to be able to install some package. OTOH new-build could install older Cabal.
So we’d need to maintain older Cabals, to be build able with newer GHCs,
that’s not fun, but not impossible.
I agree, that we could have discussed setup-depends more,
hopefully no-one disagrees about them (and dcoutts took very conservative
approach there).
Also taking them out of Cabal, doesn’t mean that package becomes unbuildable,
there will be just more luck involved.
About convenience libraries I agree even more. We should discussed them more.
There are questions I’d might to ask, but I guess it too late
Or maybe not too late, but for another thread:
what is convenience library name clashes with the library on package,
say I define convenience library fancylib-lens, which is on Hackage, but maybe
also after I made my package?
I guess, some shadowing happens? Is there a warning?
But we have quite formal feeling proposals about `provides`,
and `or-dependencies / multi-way-flag / depends`, and
formal process would help to get them thru (or say no, with an explanation)
>
> So how about this script, which is how web standards work:
>
>Cabal changes need to be informally proposed and discussed.
>But the advancer can also write a PR and get it merged in
>as an experimental extension, to be trialed for the next
>major release series. Eventually it gets standardized.
>
> Edward
About the original topic, I’d require “ a history of quality contributions”, so
something between (2) or (3).
I don’t like many rules, also making fair but non-abusable ones is difficult,
but as we have this conversation,
the outcome should be well defined (also how we change the rules).
As with (2) does every accepted PR counts, like single character typo fix in
the documentation?
And I don’t know how to define “quality contribution” :(
(Maybe I’m just to scared about dramas happened elsewhere)
Related to this, a thought I had for some time:
I’d like to split Cabal and cabal-install repositories.
Pros:
- `cabal-install` can be much more liberal in giving out commit bits, as you
cannot make too much damage here.
- we already have `hackage-security` as a dependency between them.
- the CI setup could be simplified, resulting into
- their tests could do more things: `Cabal` parses all `Hackage`, changes to
`cabal-install` doesn’t need to do it,
and vice-versa, fixing ui of cabal-install doesn’t need to do package tests
of Cabal.
- their other processes could be different too.
Cons: Simultaneous development is almost impossible. And this is almost a
show-stopper.
- `cabal-install` would need to lag one release behind `Cabal` (development
agains released `Cabal`).
This could work as `Setup.hs` should work to install packages requiring newer
Cabal (isn’t it how it works nowadays?).
There will be a problem when newer `Cabal` won’t accept build-plan created by
solver
in older `cabal-install` (proposals mentioned above), but I hope it won’t be
a huge issue.
- To make this work we’d need to release more Cabal major versions,
so there aren’t many breaking and intrusive changes accumulating. But that’s
good thing, isn’t it?
Or it could be a quality win to separate them. After all `cabal-install` is not
the only consumer of `Cabal`.
`stack` uses it very limitedly atm though (i.e. to extract dependencies and
maybe verify install plan?)
I don’t know what `ghc-pkg` does.
IMHO we should develop Cabal-the-library with highest standards (starting with
having detailed CHANGELOG) for library development.
Now we might have been too focused on developing Cabal for cabal
