Stack ensures that the Haskell environment stays as specified. I find it
very useful that GHC is included in this spec as we don't necessarily
(want to) control the external installations. For example, when GHC 8.0
has been pushed in the official repos of Arch Linux, stack just
(re)installed the old one transparently and I didn't had to deal with it
in my projects, nor rollback the Arch Linux package.
If new users try to use Haskell on such distros, they would better use
stack with the latest LTS (implying GHC 7.10.3) than use GHC 8.0 from
the official repo and deal with broken dependencies during the
transition period. Moreover it is still possible to use "ghci" and "ghc"
for small scripts and interactive sessions.
I agree that stack should be the recommended build tool, hence:
1) For the download page, I would say the "minimal install" (or "net
install") is stack and should be on top.
2) On Linux distros where the HP is just a meta-package, as long as it
brings the latest haskell-stack package, it shouldn't do no harm (but by
default stack may not even use the provided GHC, depending on the
current LTS and on the GHC version in the repo).
3) For bindist HPs, if the GHC version doesn't match the one used by
stack, I don't see the point of including stack in the HP (or using the
HP at all) because the first thing stack will do is to download another
GHC. Maybe it would be possible to provide a default stack.yaml in the
HP that would force stack to use a resolver associated with the provided
GHC and libraries, in which case it would make more sense. Maybe bindist
HPs could be automatically generated to match Stackage's LTS releases? A
"HP Full" release could provide more packages from the LTS.
4) A "get-started" example using stack should be added on haskell.org
Cheers,
Sylvain
On 30/08/2016 12:23, Simon Marlow wrote:
The choice boils down to whether you want stack to manage your GHC
installation or not.
I personally find it distasteful. This has been the biggest blocker
for me using stack, it wants to control more of my workflow than I
want to give it, leading to an overlap of responsibilities. (I do use
stack, but only with external GHC installations, and I often get into
a mess when it tries to download another GHC)
Having said that, is it better for new users to delegate the GHC
installation to stack? I don't know. It certainly has the downside
that you can't just type "ghci" and get a prompt.
The world seems simpler when it consists of
- GHC installations
- build tools that use your GHC installations and manage local package
building
But when my build tool manages my GHC installations, there's now a
layer of abstraction in the way of GHC and I can't figure out how to
interact directly with GHC any more. Also I can't use cabal (which I
often do).
So, I'd argue for HP minimal to be the default download option. By all
means recommend stack as the default build tool - I'm sure it's less
problematic for most people to get Stackage by default, and cabal
isn't set up to use Stackage out of the box.
Can't we get rid of HP Full? I don't see a use for that any more.
Cheers
Simon
On 29 August 2016 at 16:29, Nicolas Wu <nicolas...@gmail.com
<mailto:nicolas...@gmail.com>> wrote:
Hello,
I think having multiple options is confusing to beginners, and so
I'd like to see a single download option on the download page.
For me it's important that we have a way for beginners to use
tools like ghc and ghci on the command line directly in order to
run small throw-away programs.
The decision about how to manage projects and their dependencies
should be open and isn't for beginners, whether that be using
stack or cabal: both have their merits, and I don't want to push
one over the other. The default installation should provide both
of these as well as other tools core to building ghc.
As such, I'm in favour of having the HP as the only option.
Nick
On Sat, Aug 27, 2016 at 5:50 AM Jason Dagit <dag...@gmail.com
<mailto:dag...@gmail.com>> wrote:
Hello all,
I just realized that the Minimal installer listed first on the
Downloads page (https://www.haskell.org/downloads
<https://www.haskell.org/downloads>) is deprecated and "dead".
This creates an unfortunate situation where our top suggested
way to get haskell immediately tells the user it's dead.
I think that we should remove mention of the minimal installer
ASAP on the grounds that the HP now comes in minimal and full
variants.
Furthermore, I would like to make the recommendation that we
list the HP above other methods as even the minimal HP
installer ships with stack (at least on windows it does).
Between the two changes, I think the first one is crucial and
the second one is merely reasonable.
Thanks,
Jason
_______________________________________________
Haskell-community mailing list
Haskell-community@haskell.org
<mailto:Haskell-community@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
<http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community>
_______________________________________________
Haskell-community mailing list
Haskell-community@haskell.org <mailto:Haskell-community@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
<http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community>
_______________________________________________
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
_______________________________________________
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
