[Haskell-cafe] Handling absent maintainers

Ivan Lazar Miljenovic ivan.miljenovic at gmail.com
Thu Jul 15 23:02:56 EDT 2010


Alexander Solla <ajs at 2piix.com> writes:

> On Jul 15, 2010, at 6:49 PM, Jason Dagit wrote:
>
>>  Everyone has their own branch of everything they contribute to,
>> listed right on the website?  This is inline with another idea I've
>> heard where we'd have a 'stable' hackage and 'unstable/dev'
>> versions.  But, how does this work for resolving and communicating
>> dependencies?
>
> One thing cabal is missing is a... cabal to pick and choose APIs.

Duncan Coutts keeps telling me that there's no such thing as the Haskell
Cabal... ;-)

> Imagine:
>
> 1. Hackage-stable
> 2. Multiple Hackage-dev's, each based on current Hackage-stable (if
> they're too old, they're out of the running for inclusion in stable)
>
> Hackage-dev packages are submitted to the Hackage-stable Cabal, which
> picks and chooses the nicest code.  Hackage-stable incorporates that
> code.  The Cabal would be responsible for coordinating dependencies.
> (This would potentially involve some programming from members of the
> Cabal)

A few things I find that might not work with this approach:

1) Needs more manpower for people to vet each package; this could also
   be a problem when the person doing the vetting is good in the field
   of Haskell API design but might not be that versed in the problem
   domain, and thus might pick the version that has the better API
   solely from a programmers perspective rather than soemone that has to
   use that code.

2) Makes it difficult to write code depending upon quirks of an
   individual package, if the blessed API implementation gets changed.

3) How will we deal with a change in the choice (or even just the
   version) of the blessed implementation in terms of versioning of the
   API package?

4) For abstract libraries, you're constraining the creativity, etc. of
   package designers to meeting some abstract API design.  This might
   work for new data structure implementations fitting into a class
   definition to be able to use pre-defined code, but I'm not sure how
   well it will work in terms of, say, an HTML templating library.

> This is kind of in line with how Haskell Platform is being built up.
> They take popular/useful packages with mature API's and promote them
> to the platform if there's enough interest.

And this is partly a community-driven effort: the platform contains the
libraries that seem to be used by the community (see Don's recent emails
about getting some of the more popular Hackage packages into the
Platform).  Hackage 2.0 should also help in this regard with the
promised availability of commenting/voting on packages.

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
IvanMiljenovic.wordpress.com


More information about the Haskell-Cafe mailing list