Alexander Solla
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@gmail.com IvanMiljenovic.wordpress.com