Improving the "Get Haskell Experience"

Mark Lentczner mark.lentczner at gmail.com
Sun Jul 19 11:46:57 UTC 2015


 I'm glad to read the variety of response, and want to summarize and
respond to the most common points:

*stack is too new *& *having two package managers will confuse*
— It is indeed new, though it has arrived very well formed, and has gained
a lot of users in short order.  There are two reasons why I think we should
be including it (or rather, including the version a few months down the
road when we do the next major HP):

1) It's approach to package db organization is very good,
2) I would be better for all that stack were part of the suite of tools,
rather than an alternative suite.

Too be clear: I don't anticipate stack replacing cabal - different tasks
will need one or the other. But I would like to see them unified in package
db management.

*nix-like package management*
—  I'll be honest: I don't think nix-style package management is all that
useful. Enabling the package machinery to be able to support all those
different package builds is fine. But it seems the devil is in the user
experience of the tools that manage it. Until we see what use cases those
tools support, I really have no way to evaluate what extending package dbs
this way will add.

*possible change to cabal sandbox handling of the global db*
— Of course this will improve more complex builds for people who download
the HP - but does so by reducing the HP install to a minimal install. This
is fine, but I think what we proposed goes further.

*pre-built package binaries are good*
— Yes, especially on Windows, but I'd like to see a way that users can get
those binaries, easily, and securely, without bloating the HP download. At
present, users have to download 150MB ~ 230MB of installer - it is heavy!
If we can make it so that users only have to compile a package the first
time they use it in any project, for many this is ideal: you start minimal,
incur cost is only once on first use, and build exactly in your system
environment. If we augment this with a "binary repository" then we can let
users decide to trade the compile cost for the download cost.

- Mark

Sorry for slow, group response, I'm still on vacation!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150719/fe4e2ae9/attachment.html>


More information about the ghc-devs mailing list