Stepping back: what do we want from platform releases?

[Gregory Collins]

Duncan Coutts <duncan.coutts at worc.ox.ac.uk> writes:

> All,
>
> On reflection, we (Don and I) think we've asked a question that has too
> many assumptions behind it that are not universally agreed. Perhaps we
> would do better to look at the slightly more general issue. 
>
> The question we asked about API stability in minor releases already
> assumes a lot about the frequency of major and minor releases and indeed
> what a major or minor release actually is; what their purpose is.

My two cents:

My understanding of the purpose behind the Haskell Platform project is
that it:

  * provides a convenient installer

  * provides a batteries-included set of "canonical" libraries, with a
    lukewarm guarantee that the libraries work and have been tested
    together.

The concrete problems that we're trying to solve:

  * bootstrapping a functioning Haskell system (with cabal & a
    reasonable library set) is a multi-step, time-consuming process

  * hackage (thankfully) has a low barrier to entry, but that also means
    there's a mishmash of stuff there in varying states of
    quality/testedness/"only-works-with-ghc-6.6"-ism. Evaluating the
    quality of a library can be difficult for non-experts.

  * cabal is pretty poor at handling dependency conflicts. I've wiped
    out & reinstalled the entire haskell stack more times than I would
    have liked over hard-to-resolve dependency conflicts, and I can't be
    alone in that. A goal of HP is to ameliorate that.

If we're talking about the definitions of major vs minor releases, I'm
in the camp that says that if you depend on a major version of the
haskell platform, your code should recompile cleanly against minor
releases on that line (i.e. no backwards-incompatible changes). For a
minor release, bugfixes are clearly okay, new features or modules are
probably okay (if limited in scope), and API changes are a no-no. I
suspect this meshes with most people's common-sense understanding.

***

Something that isn't clear to me is: how are we going to encourage
people posting libs to Hackage to target the platform? As a library
author, it would be really nice to be able to say:

    Build-Depends: haskell-platform >= 2009.2 && < 2009.3

and then be able to "import Network". Instead you get:

    Foo.hs:3:7:
        Could not find module `Network':
          it is a member of package network-2.2.1.1, which is hidden

If you want to target the platform as a library author, then you have to
go through your long laundry-list of dependencies and assign an exact
version to each, and you have to repeat this process every time a new
version of the platform comes out. I reckon that for many people, the
cost/benefit analysis is going to come out to "I can't be bothered."

Can this be fixed in cabal? Should we export a module "Haskell.Platform"
that re-exports all of the platform modules? (That's a modest proposal,
of course, compilation time would go through the roof, but it'd be
convenient, and unless I'm missing something "convenient" is the raison
d'etre here.)

G.
-- 
Gregory Collins <greg at gregorycollins.net>