Proposal: Add-on packs

[Mark Lentczner]

On Wed, May 29, 2013 at 6:44 PM, Jason Dagit <dagitj at gmail.com> wrote:

> Trying to respond to this, I run smack into the question of, "Well,
>
what value does/should the HP provide?" ... I think people who want
> to get started with Haskell, and have something simple but full
> featured to install, are the audience. Would you agree?
>
> My impression is that the primary value of the HP is in having the HP
> sign off on things so that newcomers have some clue as to what
> packages to get started with. The secondary value being the convenient
> packaging itself.
>

Not quite: The primary value of HP is that it is a stable reference set of
versions on which development can be based. If I target my libraries to HP
releases, and then you want to use my libraries, you can target your work
to HP release plus my libs... And if some other person wants to deploy some
software on a server farm, they can target HP releases, and my libs and
your libs and.... it should all work. By target here I mean code to, test
to, and release based on. For many deployment situations, working on known
stable sets is far more important than using the bleeding edge of every
package that cabal thinks it can make to work.

Stable here means both stable versions that work together without "cabal
hell", as well as stable in API (won't break your code every release), and
stable from the perspective of the community feels these packages have
stood the test of time and use and are a solid choice to depend on. They
are the "go to" packages for use.

A secondary value of HP is that the packaged versions both get over the
boot-strapping problem of GHC and cabal, and start with that stable set of
libs already there. This value reduces the cognitive load on users, both
new, and otherwise - that just want to get on with programming their
application, without all the yak-shaving.

So, to take it back to WxHaskell: Is that project stable in this sense? The
hackage project has had no release for a year. There appear to be to
different lines of development going on and two different repos. There also
seem to be several different layers of abstraction... This may all be fine
and stable... or it may not. It isn't clear, and I don't know how widely it
is used. It looks like there is now some effort to bring it up to date ...
I hope that means it will reach a stable usable release point soon. Note
that part of this is resolving the build and install issues - which on Mac
and Windows look formidable at present.



> It's about reducing duplication and making things convenient for the
> masses (the secondary value of the HP as I put it above). If the HP
> team can get, say, Gtk2hs built in a redistributable way, then (the
> logic goes) it would be nice to reuse that effort instead of forcing
> users to reproduce a non-trivial to configure build environment.


I still don't understand: If the Gtk2hs team cannot do this, why do you
think the HP team can?

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/haskell-platform/attachments/20130529/b8f25819/attachment.htm>