Improving the "Get Haskell Experience"

Sun Jul 12 17:13:37 UTC 2015

I think it depends somewhat on operating system, since there are
permissions issues to be dealt with regarding user vs global installation.
In principle though: I think the HP installers would install to a
non-stack-specific location, and then stack would simply use that GHC based
on its inclusion in the PATH. (I'm also guessing this will tie in nicely
with Linux distro packages, which would likely want ghc to live in
/usr/bin).

On Sun, Jul 12, 2015 at 10:11 AM Dan Burton <danburton.email at gmail.com>
wrote:

> Stack has the capability of downloading and installing GHC on demand, as
> well as auto-updating itself. Both of these features, by default, occur in
> subdirectories of the user's home directory. (Slightly different on Windows
> but same idea.) Would the Platform install GHC to the stack location
> directly, or install it system-wide as previously? (Stack can still make
> use of GHC anywhere on your path.)
>
> On Sunday, July 12, 2015, Michael Snoyman <michael at snoyman.com> wrote:
>
>> I'm +1 on nailing down an LTS release cycle, I've been pushing for it,
>> and planning that it would happen after the first few releases. I'm fine
>> with doing it starting with the next release if that's desired.
>>
>> The cygwin/msys conflict is a problematic one. stack has more flexibility
>> addressing this than MinGHC did, since stack can control the PATH more
>> directly. What we do now is, by default, add msys to the beginning of the
>> PATH, and provide a command line option to not use msys at all. I believe
>> this combination has addressed the bug reports we've received in the past.
>>
>> That's not to say I'm opposed to generating binary databases; I'm
>> actually in favor of having that option for all platforms at some point
>> (there's an open stack issue about it[1]). But it's a significant amount of
>> work, and I think if possible we should defer it until we've figured out
>> initial integration points.
>>
>> [1] https://github.com/commercialhaskell/stack/issues/117
>>
>> On Sun, Jul 12, 2015 at 9:20 AM Gershom B <gershomb at gmail.com> wrote:
>>
>>> I’m ccing cabal-devel, as that list seems pertinent to this discussion
>>> too. In general I’m in favor of unifying efforts such as this.
>>>
>>> For windows, I’d still like the _option_ to get prebuilt library
>>> binaries for the full platform db. The modularity means that they can be
>>> just downloaded in a separate folder now, rather than installed into e.g.
>>> the global db? If so, that’s a nice win. Here is my motivation — I tried
>>> the minghc installer and it mainly worked, but it played terribly with
>>> cygwin, which I use pervasively. So I found myself in a situation where one
>>> set of paths worked with cygwin, and the other set of paths let me build
>>> the network library. I still have some anxieties about those sorts of
>>> issues, and being able to “just download the binaries” would make me feel a
>>> bit safer about at least one workaround should things get too muddled up.
>>>
>>> If we synchronize LTS and “platform libs,” then I would like A) some way
>>> of distinguishing “blessed platform libs” from “other libs in LTS” (to
>>> solve the “curation problem” which has always been a goal of the platform)
>>> and B) a standardized release schedule for LTS.
>>>
>>> (And, of course, I assume this will _not_ be for the platform release
>>> upcoming, which is due very shortly, but we’ll have a longer lead time to
>>> integrate and shake out all the various issues and test, etc.)
>>>
>>> —Gershom
>>>
>>>
>>> On July 12, 2015 at 12:04:22 PM, Mark Lentczner (
>>> mark.lentczner at gmail.com) wrote:
>>> > *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop
>>> > shipping pre-built packages, so we banish cabal hell, and have a single
>>> > common way to 'get Haskell' that just works.*
>>> >
>>> > At ICFP '14, there were several long group discussions of the state of
>>> > "getting Haskell", including Haskell Platform, Stackage, and other
>>> > approaches. Over the last year, there have been a few more public
>>> > discussions and evolution on the ideas, and other installer
>>> developments.
>>> > In particular, Stackage's LTS package sets are a direct development
>>> from
>>> > this work, and the release of stack has offered new options.
>>> >
>>> > Today, drawing from all this good work and ideas from so many, we'd
>>> would
>>> > like to propose a concrete plan:
>>> >
>>> > - Haskell Platform becomes the standard way to get *GHC* and related
>>> > tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a
>>> > user-friendly, cross-platform installer that gives a standard way to
>>> "get
>>> > Haskell" for most users.
>>> > - Use the *stack* model for package installation:
>>> > - The global db has only the GHC packages
>>> > - There is a package db for each curated set, Haskell Platform
>>> > becomes one such set
>>> > - Projects each have their own package db, much like sandboxes.
>>> > - Haskell Platform's installer will no longer include pre-built,
>>> > pre-installed packages other than GHC's set. Instead, it is configured
>>> so
>>> > that *stack* can be used to build and install, on as needed, the
>>> > corresponding Haskell Platform release packages.
>>> >
>>> > We think this plan solves many different community needs:
>>> >
>>> > - We have a clear way to "get Haskell" that works for a wide variety of
>>> > use cases.
>>> > - HP installer gets much smaller, and about as minimal as a working
>>> > installation can get.
>>> > - By leaving most packages out of the global database, users of
>>> > cabal-install, will now have far fewer problems. Sandbox builds should
>>> now
>>> > never give users "cabal hell" like warnings.
>>> > - By building and installing the Platform packages into it's own
>>> package
>>> > db, users get the benefit of building and installing these common
>>> packages
>>> > only once per system, yet can easily bypass them for any given project
>>> if
>>> > desired.
>>> > - Since the Platform packages are now built and installed as needed,
>>> > installing on smaller systems or servers without OpenGL will work.
>>> >
>>> > To do this, we have a bit of work ahead of us: We need to settle on
>>> > installation layout for each OS (including getting msys into the
>>> Windows
>>> > installer); decide on the naming and versioning of the Platform
>>> package set
>>> > (is it just LTS? does it have a different life cycle? etc...); getting
>>> > *stack* ready such a distribution; and configuring (or updating)
>>> > *cabal-install* to support the three-layer package db scheme. We think
>>> we
>>> > can do this in short order.
>>> >
>>> > We recognize this represents a significant change for the Platform, and
>>> > will require buy-in from the various parts, especially *ghc*, *cabal*,
>>> and
>>> > *stack*. We'd like to get your input.
>>> >
>>> > - Michael & Mark
>>> > _______________________________________________
>>> > Libraries mailing list
>>> > Libraries at haskell.org
>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>> >
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>  --
>>
> You received this message because you are subscribed to the Google Groups
>> "haskell-stack" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to haskell-stack+unsubscribe at googlegroups.com.
>> To post to this group, send email to haskell-stack at googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/haskell-stack/CAKA2JgKYuBMU5wtbjGV72dDKvSJePWbhoZeRCuJYR9SFoV8EDw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/haskell-stack/CAKA2JgKYuBMU5wtbjGV72dDKvSJePWbhoZeRCuJYR9SFoV8EDw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>
>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> -- Dan Burton
>
> --
> You received this message because you are subscribed to the Google Groups
> "haskell-stack" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to haskell-stack+unsubscribe at googlegroups.com.
> To post to this group, send email to haskell-stack at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/haskell-stack/CALSygwfNjyxWFL0y4-_5aSyZZVQSeb5705MzZnaM4Q7GA2MLBg%40mail.gmail.com
> <https://groups.google.com/d/msgid/haskell-stack/CALSygwfNjyxWFL0y4-_5aSyZZVQSeb5705MzZnaM4Q7GA2MLBg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150712/1ff86e34/attachment-0001.html>