On Windows, the reason I used to use the Platform was that it came with an installed network library, and installing the network library on Windows is a real pain (and often fails). Unfortunately it was incredibly brittle, a single attempt at upgrading network from some newer package usually trashed my Haskell install and required a wipe and restart. Nowadays I use https://github.com/fpco/minghc which can actually install network, and I've had zero problems. I can get up to the platform with one invoke of cabal, and if someone decides to require a new network, it just works. I think the Platform now gives a worse user experience on Windows, so the ideas (or names) probably need migrating around. Thanks, Neil On Sun, Mar 22, 2015 at 8:47 AM, Heinrich Apfelmus wrote:

Mark Lentczner wrote:

...

I'm wondering how we are all feeling about the platform these days....

I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second option) pretty much steers folks away from it. Of the per-OS download pages, only the Windows version even mentions it.

Does this mean that we don't want to consider continuing with it? It is a lot of community effort to put out a Platform release - we shouldn't do it if we don't really want it.

That said, I note that the other ways to "officially get" Haskell look, to my eye, very ad hoc. Many of the options involve multiple steps, and exactly what one is getting isn't clear. It hardly looks like there is now an "official, correct" way to setup Haskell.

The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new features and development have clearly changed the landscape for use to reconsider what to do.

I don't think the status quo for the Platform is now viable - mostly as evidenced by waning interest in maintaining it. I offer several ways we could proceed:

*1) Abandon the Platform.* GHC is release in source and binary form. Other package various installers, with more or less things, for various OSes.

*2) Slim the Platform.* Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell.

*3) Re-conceive the Platform.* Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction.

Thoughts?

Thanks a lot for your hard work on the platform!

I myself am an avid user of the platform (OS X), because for me, it's the easiest way to install Haskell on a new machine; I just did so the other day.

The only time when the platform seems to be a handicap is when a new version of GHC is being released and I would have to update my packages. Usually, I don't test them with the new version and rely on pull requests instead.

Best regards, Heinrich Apfelmus

-- http://apfelmus.nfshost.com

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Sun, Mar 22, 2015 at 10:17 AM, Neil Mitchell wrote:

On Windows, the reason I used to use the Platform was that it came with an installed network library, and installing the network library on Windows is a real pain (and often fails). Unfortunately it was incredibly brittle, a single attempt at upgrading network from some newer package usually trashed my Haskell install and required a wipe and restart.

Slightly OT: If you ever want to prevent cabal from trying to install a different version of a package (since you know it won't work, or will break things) you can put something like this in your cabal config: constraint: network installed I do this for template-haskell, since it's not possible to reinstall but cabal would occasionally try it. I can imagine it would work well to prevent the scenario you describe with network. Erik

On Sun, Mar 22, 2015 at 11:24 AM, Herbert Valerio Riedel wrote:

On 2015-03-22 at 11:17:21 +0100, Erik Hesselink wrote:

[...]

...

I do this for template-haskell, since it's not possible to reinstall but cabal would occasionally try it. I can imagine it would work well to prevent the scenario you describe with network.

Why isn't it possible to reinstall TH (unless you also need to depend on the `ghc` package)? We even explicitly allowed template-haskell to be reinstallable again in Cabal as there didn't seem any reason to forbid it anymore (it's no different than e.g. `bytestring` which is reinstallable as well):

https://github.com/haskell/cabal/commit/ffd67e5e630766906e6f4c6655c067a79f73...

This was based on my experiences from some time ago. Looking at it now, I think it was just that the dependencies for template-haskell were too loose, i.e. it allowed different major versions of base. When a new version of GHC was released and I was trying it out, it would always try to install the older version, and this never worked. Now that you fixed these constraints (thanks!) it seems you can reinstall, as long as it's the same (major) version. It still prints this ominous warning even in a sandbox: Warning: The following packages are likely to be broken by the reinstalls: ghc-7.8.3 But everything seems to be fine when passing --force. So I guess I can remove the constraint... Erik

On Sun, 2015-03-22 at 09:17 +0000, Neil Mitchell wrote:

On Windows, the reason I used to use the Platform was that it came with an installed network library, and installing the network library on Windows is a real pain (and often fails). Unfortunately it was incredibly brittle, a single attempt at upgrading network from some newer package usually trashed my Haskell install and required a wipe and restart.

Nowadays I use https://github.com/fpco/minghc which can actually install network, and I've had zero problems.

Can we just include this fix into the platform installers? As Mark says, the Platform has decent automated build & test infrastructure so it shouldn't be that hard. As I understand it the network problem is just to do with how much of mingwin we include and not really related to "min" vs "max" installers. Duncan

On Sun, 2015-03-22 at 10:52 +0100, Herbert Valerio Riedel wrote:

My biggest complaint about the current HP is that it pollutes the global package database with additional packages which leak into `cabal sandbox`es. This causes `cabal sandbox` to provide quite different sandbox environments for HP environments compared to a non-HP environment without those additional packages pre-installed.

Currently GHC/Cabal knows about a global package db and a user package db (the user pkg db is is what gets replaced/shadowed by cabal sandboxes). Maybe we need a 3rd package db sitting between the global and the user package db that interacts better with cabal sandboxes?

I think this is a good idea. As far as I can see there's no conflict between the advocates of mini and maxi installers (as aimed at new users) except for this behaviour of new sandboxes. All we need to do is make "cabal sandbox init" start with a minimal package set, rather than taking the global package db. It's true that the ghc/platform installers could help with this, e.g. by shipping an environment file (a new 7.10 feature) that lists all the core packages, and cabal-install could use this as a basis for new sandboxes. Duncan

On Sun, Mar 22, 2015 at 10:23 AM, Yitzchak Gale wrote:

Mark Lentczner wrote:

...

1) Abandon the Platform…

2) Slim the Platform. Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell.

3) Re-conceive the Platform. Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction.

I vote for (3) but in a way that it would *not* be much work. We should definitely do the Platform, but with much *less* work.

+1

The most important reason we need the Platform is as a default selection of quality basic libraries. We should not abandon that concept. Curated package sets do not replace that - the Platform is not just packages that build together. Nor do OS packagers. The platform is a community-wide set of basic default packages that are mature, well tested, all work together well, and stable.

The second most important role of the Platform is a web site where you can get a clear picture of how to download and install a default Haskell installation for your platform, and a simple view of where we are in the parade of releases. That should also continue.

The hardest work of the Platform was its role as a way to bootstrap a Haskell installation. That is what made it so hard for HP to keep up with GHC releases, and what consequently gave people the impression that HP is always old. That work doesn't need to be done as part of the Platform anymore. We should leverage other good work people are doing to create installers, and stop doing it as part of the HP process.

The most important part of an HP release should be a cabal package that provides the packages in the platform, at the right versions, with a specification of the recommended GHC version as a pre-requisite.

Perhaps we can also provide an HP-branded slick installer for some platforms that does everything in one click, built as a thin wrapper of some existing installer. But that should not delay the official release of an HP version. It's just a nice-to-have extra.

Once we pare down the work needed for an HP release, we should release new versions of HP quite often - *more* often than GHC releases, not less often.

Another thing we should fix is the (now false) impression that HP gets in the way of installing other packages and versions due to cabal hell. We should make "require-sandbox" the default setting in the cabal config file. I would go further - I would add a cabal feature to create a sandbox automatically unless "--user" or "--global" is specified explicitly. I would make "foo installed" a default constraint (that is easy to override) for all platform packages, which solves virtually all cabal hell problems (assuming you are using a sandbox) and will not keep things old if we release often.

One of the original goals of the HP was to try and reduce cabal hell issues, but we've since seen a great deal of work in trying to solve those problems by other means. Similarly, one of the original goals was to improve Windows installation, but that too seems to have moved on. With these changes in the landscape, it's no wonder the HP doesn't seem to have much public uptake these days. As present, I think we do still need something like HP, albeit recast to fit the new landscape. The goals of Stackage and LTS are quite different, and thus they cannot fill the role that HP does/did. ... For me, the HP has served a couple roles. First (in no particular order): to serve as a one-click install for getting Haskell up and running on a new computer. Second: to serve as a stable and coherent snapshot of the Haskell ecosystem. This latter purpose seems, imo, to be the more important one going forward. In the enterprise setting —including the enterprising FOSS community— it's important to have checkpoints as a way of tracking backwards compatibility. While most developers focus on getting the shiniest newest things, this backwards support is extremely important both for maintaining infrastructures and for introducing new folks to the community; for both these groups, the newest and shiniest things may not be easily available/usable due to economic concerns. The "preserve compatibility with the last X versions" model works well for dependencies like GHC, but it's not always clear (in retrospect) which versions of hackage libraries were the contemporary/standard versions corresponding to each GHC version. Thus, providing these sorts of checkpoints is a necessary part of community building— for commercial enterprise, FOSS enterprise, and newcomers alike. Now that we have our foot in the door with various distros, the goal of providing checkpoints can also help to satisfy the one-click install goal, since the checkpoint provides distro managers guidance on how to support a coherent snapshot of the crucial/main libraries needed to get up and running. (Also, this could potentially provide an avenue for reducing the work involved in releasing the HP; that is, by relying on distros to deal with the distribution aspect, we could focus more on just building/testing the configurations for each release.) ... As mentioned elsewhere in the thread, the outdatedness image of the HP is definitely a problem. The salient solution here is to try and release more often than we do now. Of course, with the amount of work the HP currently takes for each release, that's not really tenable. When the HP started we all knew it'd be a bunch of work, but that work seemed like a good idea at the time. Now that the goalposts have moved, that work seems more like an unnecessary burden. So, what could the HP offer today which would be worth the work it takes to do so? -- Live well, ~wren

On 2015-03-22, at 15:59, Michael Snoyman wrote:

2. A method for installing GHC and build tools. I personally think that it makes sense to separate out this aspect of the platform from all others. MinGHC is an example of such a project: a minimal set of functionality for bootstrapping a more complete Haskell development environment. 3. Prebuilt binary package databases. As I've mentioned in the past, and others have here, there are problems with the current approach of putting the packages in the global package database. I'd personally rather see this aspect of the platform give way to more robust solutions.

I think a smaller task force dedicated to improving the tooling situation is the best next step, and I'd be happy to kick off such an effort with other interested individuals.

I’d be very happy to contribute to this effort. In fact, I’ve already spent some of time addressing these issues. Halcyon already provides a method for installing GHC, cabal-install, build-tools, and other Haskell programs — on OS X, and many Linux distributions. FreeBSD and Windows are on the roadmap. Additionally, Halcyon allows you to declare native OS libraries as build-time (or run-time…) dependencies for Haskell programs. They will be installed into a user-controlled directory, by wrapping around the native OS package manager. Currently, this is supported on Debian-based and RedHat-based Linux distributions, which partially implements a long-standing cabal-install feature request: https://github.com/mietek/halcyon/issues/38 https://github.com/haskell/cabal/issues/571 See the Haskell Language source code for an example: https://halcyon.sh/examples/#haskell-language See the Halcyon reference for details: https://halcyon.sh/reference/#halcyon_sandbox_extra_os_packages https://halcyon.sh/reference/#halcyon_extra_os_packages -- Miëtek https://mietek.io

On 2015-03-23 at 11:20:36 +0100, Thomas Miedema wrote: [...]

For most users, we recommend installing the Haskell Platform http://hackage.haskell.org/platform/ instead of GHC. The current Haskell Platform release includes a recent GHC release as well as some other tools (such as cabal), and a larger set of libraries that are known to work together.

Btw, I've always wondered a little bit about the last part, namely "set of libraries that are known to work together"... what is actually meant by that? Does it simply refer to providing a selection of package-versions that form a valid coherent/simultaneous Cabal install plan? Cheers, hvr

A common sentiment I see here is that the Platform always seems out of date. That has always been true, and to a degree by design: It is the stable set, not the wild west. Historically, the first release of a major new GHC was seen as needing a bit of a trial period before we enshrined it in a Platform release. Hence, they lagged. There are also other concerns like stable release schedule (which the Platform has been poor at, but has always been a goal). GHC has made great strides in being much more stable out of the gate. And the Platform has been significantly automated recently. For example, there is already an Alpha of the Platform for 7.10 RC3. But it still takes person-power to run it, test it, and get it out. And there is still the issue of stable release times. If you want latest GHC, and latest libs - then Platform is not the way to go. A solid question is: Where do we want to direct the mass of the community? At head? At latest release? At some older, but now stabilized point? What do we want their experience to be? We will best served if the answer is pretty much right for the bulk of the community: not just newcomers, not just people doing production work, not just hobbiests... all of them. Most other language systems manage to have a single distribution that works for the majority of the community, and most of them are content to have much better stability and support. Python put out 2.7.0 in 2010, and 2.7.9 last Dec. It is still supporting 2.7 line (with source and library compatibility) while it is off releasing 3.3 line. This would be for us like deciding to support and update 7.8, and the pre-FTP Prelude for another four years. Which wouldn't be so bad... ​

On March 23, 2015 at 10:02:11 AM, Mark Lentczner (mark.lentczner@gmail.com) wrote:

I do too...! But follow the new Haskell.org pages like you are a user "just want to install Haskell"... you'll never end up with the Platform.

It looks like the Platform deprecated on the Haskell.org site for Linux and OS X in June , and for Windows in Jan

. *Infrastructure team:* Was there a discussion and decision to do that somewhere?

I thought the current language on the page was rather balanced? That said, the initial people working on the site strongly leaned towards recommending minimal downloads over the platform in general, and as OS X and Windows developed good minimal installers the site was updated to point to them. In the editorial process on the site we, actually worked to make sure the platform _was_ highlighted more than it had been. And every time the site has come under public review (three times thus far, at least) the issue of minimal installers vs. platform was contentious, but with the former voice dominating. Note that there remains an issue under discussion about making the presentation of the two alternatives more balanced yet: https://github.com/haskell-infra/hl/issues/55 (patches and pull requests welcome!). In any case, here is my problem. I would like us to be in a situation where we can always say “use the platform” to new users. I don’t think we are there, because new users will insist on using whatever libraries they read about as the latest and greatest, and those libraries do necessarily take care to ensure platform-compatability. (And if you tell them that straying from the platform is not for the inexperienced, they will snap at you and call you condescending, and insist they know what they are doing… shrug). Since we cannot mass-alter this sort of attitude among new users, then the next best thing would be to mass-alter the attitude among people who write not-platform-compatible libraries. But that is hard to do as well! (A “badge” on hackage for platform-compatible packages would do wonders, I think). So, in the meantime, we need to get the centralized, uniform platform installers into a shape where we _can_ uniformly recommend them. And, as I suggested, it seems to me the way to go about doing that is decoupling the “library curation” element of the platform from the “installing haskell” element. That, or ruthlessly marking packages on hackage that do not work with the current platform with a big red X :-) Cheers, Gershom

On 23 March 2015 at 15:01, Mark Lentczner wrote:

On Mon, Mar 23, 2015 at 3:01 AM, Simon Peyton Jones wrote:

...

Like Richard, I was astonished by this. I always thought that the Haskell Platform was the route of choice to install GHC, together with a respectable set of libraries. It’s certainly what I install on a new machine!

I do too...! But follow the new Haskell.org pages like you are a user "just want to install Haskell"... you'll never end up with the Platform.

Separate from any opinions about what's best going forward, chiming in on a bit of history for the new homepage, my motivations were: I wanted newbies to come to the site and find a download page *within the Haskell.org site* (not going to another site with a different design) that gives them something current and usable. I added the manual GHC install guide (now gone) because that is the method I was most familiar with. I've never used a HP release. So I surveyed the current crop of handy installers and judged community use of these things from mailing lists, reddit, IRC, etc. I saw enough interactions with newbies that the HP was not being recommended anymore due to its old GHC version and old packages (at the time of making that change on the page, the current HP release was very old), and the problem of the global database and installing new things. I'm not really familiar with the user experience of this, but people don't seem to like it. So the Linux install became recommendations of OS-specific installers (e.g. the Ubuntu and Arch repos are often recommended), and Windows remained HP coupled with the new MinGHC (which I also saw being recommended), and OS X became linked to the GHC for Mac OS X project (again, I saw people were using that), each of which claim superiority for various platform-specific reasons over the HP releases. So that's the decision-making process that went into making the page flow like it is. Someone added this text:

Many now recommend just using a bare compiler combined with sandboxed dependencies, especially for new users. However, others prefer to start with the curated blessed set of packages in the Haskell Platform, which is available for Windows, OS X, and Linux.

Which adds choice to users ill-equipped to make choice. I didn't add it (although I understand the motivation behind it). From a web site perspective, I'd prefer the download pages just be on the site. If it's these platform-specific installers, the HP, or some new helpful installer + LTS or whatever, it should be just there under /downloads, /downloads/windows, etc. and there should ideally be one, good, current choice. The current page is a compromise, not the final product.

I suppose ironically the page does a good job of representing community opinion; i.e. there is still debate on this issue. Even though ideally the vision was for the site to be as clear as possible, I saw no uncontentious choice here.

On Mon, Mar 23, 2015 at 11:19 AM, Richard Eisenberg wrote:

- "It's always out-of-date." This statement, while true, isn't a direct indication that something is wrong.

"Perception is reality". The period when the Platform went without an update for over a year because we were waiting on ghc 6.8.3 did a lot to ruin the Platform's reputation. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On 23/03/15 17:19, Richard Eisenberg wrote:

Forgive me, all, for asking what many may think a silly question, but I must ask:

What's wrong with the platform?

It solves a problem few people seem to have. Most people want a compiler (ghc), a package manager (cabal), and libraries they can install (hackage/stackage). Instead, they are being sold HP which has its own versioning, releases on its own irregular schedule, and brings a small arbitrary set of packages frozen at an arbitrary point in time. These packages often interfere with users' desire to install their own packages. Roman

On Mon, Mar 23, 2015 at 10:19 AM, Richard Eisenberg wrote:

Forgive me, all, for asking what many may think a silly question, but I must ask: What's wrong with the platform?

You know, I don't think we ever really saw an answer to this. Well, given that we're looking at ways to make it easier to work with packages that aren't in HP when you have HP installed, indicating that some people think what's wrong is that it's hard to use non-HP libraries with HP. I don't think this is what's wrong with HP, I think it's a symptom of what's wrong. That's just making it easy to work around having installed the platform.

One non-answer to this question: - "It's always out-of-date." This statement, while true, isn't a direct indication that something is wrong.

I think this is another symptom. Yes, there are some people who always want the newest, shiniest thing. A system where you bundle up some best-of set of libraries won't make them happy, unless maintenance of the libraries moves into HP, or at least has releases coordinated with it. I don't have to have newest and shiniest. I just want to get my problem solved. But I still found that, as soon as I moved beyond doing textbook exercises to trying to solve my problems - not industrial grade solutions, just thing that would work for me - the packages I wanted to use weren't part of HP. Which led to wanting to install those packages on top of HP, which led to all the problems the current discussions are trying to solve, which led to just installing GHC and cabal. I didn't have that problem with Python or Clojure. I didn't run into it with Python until I was building enterprise-class systems. I ran into other issues that made me drop Clojure before I ran into this one. So, why weren't the packages I wanted to install in the platform? If it's really "batteries included" as the haskell.org/platform/contents.html says, shouldn't they be there well beyond just doing textbook exercises? Well, how do you find packages to solve a problem in Haskell? I bet most of you thought "Hackage" or "Hoogle". Maybe a few of you though "Google", and even fewer thought "Stackage". Which means you're probably checking a disorganized, random collection, may well be checking anything on the web, and at best are searching a curated library that's trying to do part of what HP should be doing. For Python, the answer is "search the Standard library docs". For Clojure, it's "search clojure.org". And for the people who habitually go to google for every search who are looking for things in the python standard library or the clojure library, the first links that come back will point back to those docs, not into an archive whose barrier to inclusion is compilation. And this creates secondary and tertiary problems. With Python and Clojure, in the cases where I do need something that's not in the libraries, chances are it's built on top of things that are, because those are the things people will tend to use. With Haskell, that's not the case. And should I need multiple such things - they'll probably depend on the same set of libraries. Net result: nearly two decades of writing Python code, from version 1.4 back in the last century to version 3.4 this year, I never ran into library dependency issues. So, why isn't the answer for Haskell "search the platform docs"? Maybe because there's no way to do that? If there is, I couldn't find it. There is documentation for the libraries, but it's just the haddock docs that are available in the other archives. Adding a search to the platform docs would be a nice step, but it won't solve the problem. I don't think something as integrated as python's standard library is possible, as being in the python standard library means doing maintenance and releases on CPython's schedule. Something like Clojure might be possible, with a small standard set of libraries, and a curated set that builds on that, and then the wide open archive. And of course, the platform shipping with Cabal configured to search only the curated archive by default. But that won't solve the problem unless there's broad agreement in the community that these are the places to search for Haskell packages. Otherwise, people trying to get started will wind up seeing a set of choices they really shouldn't be making yet.

On 24 March 2015 at 03:07, Mike Meyer wrote:

On Mon, Mar 23, 2015 at 10:19 AM, Richard Eisenberg wrote:

...

Forgive me, all, for asking what many may think a silly question, but I must ask: What's wrong with the platform? One non-answer to this question: - "It's always out-of-date." This statement, while true, isn't a direct indication that something is wrong.

I think this is another symptom. Yes, there are some people who always want the newest, shiniest thing. A system where you bundle up some best-of set of libraries won't make them happy, unless maintenance of the libraries moves into HP, or at least has releases coordinated with it.

+100 For me, HP is the only Haskell environment I will consider because: 1) Code I write needs to run on Mac (where it is written), Windows and Linux (where it is usually used). None of the 'build it yourself' alternatives gives a way to ensure, with confidence, that I have the same platform on each of my machines. 2) Life is too short to spend time messing around with things that won't build, out of date 'install from source' instructions and the like. 3) Haskell is not my core day job. HP always works, and is stable, predictable and documented. However, it seems to me that each HP release is essentially a snapshot, and is not really maintained thereafter. What I would love to see is for HP releases to have some level of maintenance. In particular, Michael Snowman's comment earlier that: "the version of attoparsec used by the platform today forces an old version of aeson to be used (0.6.2.1). The combination of that aeson and attoparsec version is vulnerable to an incredibly severe DoS attack for specially crafted JSON strings" goes to the heart of the matter for me.

I didn't have that problem with Python or Clojure. I didn't run into it with Python until I was building enterprise-class systems. I ran into other issues that made me drop Clojure before I ran into this one.

So, why weren't the packages I wanted to install in the platform? If it's really "batteries included" as the haskell.org/platform/contents.html says, shouldn't they be there well beyond just doing textbook exercises?

I think there are a few issues here, some of which are probably specific to the Haskell community. - There are not many Haskell users in the enterprise space who are in a position to make significant contributions of reasonably complete and 'battle tested' libraries for common problems. The OCaml community is very well served by the efforts of Jane Street in this respect. - Related to the above, there are many libraries that are incomplete (as typically the contributor will solve the subset of the problem that relates to his/her needs. - In some cases, people simply find better ways to do something that was previously messy, and this renders older (and otherwise stable) APIs and libraries unattractive. An example would be the way that Lenses have hugely simplified working on certain types of problem. - There is a huge gap in understanding between even moderately capable Haskell programmers and those at the cutting edge. I believe that this could in many cases be filled with better documentation, but the fact remains that some packages have APIs which are designed at a level of type abstraction that is unnatural to me, which makes them very hard to use. As an example, when I look at the package documentation for Data.Lens.Partial.Common, I have no clue as to where to even start. Perhaps this is a reason why there are now almost as many Lens tutorials as Monad tutorials (and with a regrettably similarly poor signal to noise ratio). OTOH, maybe my IQ is just too low to be a Haskeller :-( - I think, perhaps, that Haskell shares with Lisp communities the tendency that "we have a tool of great power available to us, so it is easier to roll our own solutions than use someone else's". I understand this, but the overall community is much better served where it can get behind a single library in each area that covers all major use cases, and which is well documented, maintained, builds cleanly and runs on all major platforms and generally remains backward compatible on upgrade. I'm not sure if I am really offering any solutions here, but FWIW, I would advocate: - HP probably does need to become smaller,of only because we do not all agree on what 'Batteries Included' means for Haskell. - HP should be maintained, at least for critical bug fixes, until at least release of next HP + a short period (maybe 3 months). - I would love to see a community effort to develop (or select from existing libraries) 'one library to rule them all' in some of the critical areas. This effort would include comprehensive documentation for every function, a meaningful set of examples and a commitment to bug fixes. The Python Standard library would be a good place to start in terms of which libraries are most needed - obviously not for API design! Finally, to Mark and the HP team: the work you have done over the years is outstanding. The work of patiently pulling together inputs from many moving targets, testing on multiple platforms and releasing is patient, challenging and unglamorous. My sincere thanks to you all. Best regards Jeremy

Because then you are working with a unique snapshot rather than one in communal use. Writing code to work with the Platform is "social gesture" that gives some hint that your code works for others. On 24 March 2015 at 14:19, Jeremy wrote:

Jeremy O'Donoghue wrote

...

1) Code I write needs to run on Mac (where it is written), Windows and Linux (where it is usually used). None of the 'build it yourself' alternatives gives a way to ensure, with confidence, that I have the same platform on each of my machines.

Why not just install GHC x.y.z and cabal freeze? (You could also use a stackage snapshot.)

-- View this message in context: http://haskell.1045720.n5.nabble.com/wither-the-Platform-tp5767291p5767542.h... Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Duncan Coutts : On Sat, 2015-03-21 at 10:54 -0700, Mark Lentczner wrote:

...

I'm wondering how we are all feeling about the platform these days....

I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second option) pretty much steers folks away from it. Of the per-OS download pages, only the Windows version even mentions it.

There was a big argument about this. I was on the loosing side. :-)

...

Does this mean that we don't want to consider continuing with it? It is a lot of community effort to put out a Platform release - we shouldn't do it if we don't really want it.

I think it is worth it, and the issues that people are complaining about wrt the platform vs minimal installers can be fixed.

...

That said, I note that the other ways to "officially get" Haskell look, to my eye, very ad hoc. Many of the options involve multiple steps, and exactly what one is getting isn't clear. It hardly looks like there is now an "official, correct" way to setup Haskell.

Right, I think there's still a great deal of value in having a simple recommendation for new users.

Absolutely! The recurring problem with decisions like the one about the recommended installers on the Haskell front page is that they are made by power users who simply lack the perspective to understand the requirements of new users. A minimal installer followed by half an hour of cabal install is an extremely bad way to sell Haskell to a newcomer. Sure, it is more flexible, but flexible is *bad* for newcomers. We are using Haskell in a few courses here at UNSW. We always recommend students to use the Haskell Platform when they want to install Haskell on their own machines. It’s one download and gives them the same packages on all platforms. Anything else just leads to lots of support questions of students trying to get their installations working to do their assignments. Manuel

One of the points of argument was that some people were arguing that the minimal installers are better for new users. I disagree, but certainly there is one issue that could be fixed that'd go a long way to resolving the particular use case with new users that was raised.

...

The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new features and development have clearly changed the landscape for use to reconsider what to do.

...

I don't think the status quo for the Platform is now viable - mostly as evidenced by waning interest in maintaining it. I offer several ways we could proceed:

Well, the people who like it don't really complain. But yes, things need improving.

...

*1) Abandon the Platform.* GHC is release in source and binary form. Other package various installers, with more or less things, for various OSes.

*2) Slim the Platform.* Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell.

*3) Re-conceive the Platform.* Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction.

I'm not sure that slimming is really needed. But I agree with the GPS approach. The current set is too small in the sense that it doesn't cover lots of things people need, and the GPS approach should solve that. We don't need to promise such high QA for the extended set, we just need to make sure they build together.

We need to remember that one of the purposes of the platform as originally conceived is to get people to sync on the versions of their deps that they're using at the moment. This is where the GPS approach shines, but it still makes sense to have some core set at the middle of that. It's true that advanced users don't need lots of things pre-installed, but they sill benefit from other developers synchronising on versions of deps, so that they can have more things work together more often.

On the argument that the platform is too big, the primary issue there is that people want to make new sandboxes that are more minimal, and with cabal's current behaviour of basing all sandboxes off of the global package db, and the platform installing lots of packages globally then we get a conflict.

But the solution is simple: make cabal sandboxes not be based off of everything that is globally installed, make new sandboxes be really minimal (though the ghc/platform installers could help with identifying what is the minimal subset).

Duncan

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On March 24, 2015 at 8:14:27 PM, Manuel M T Chakravarty (chak@cse.unsw.edu.au) wrote:

...

Right, I think there's still a great deal of value in having a simple recommendation for new users.

Absolutely! The recurring problem with decisions like the one about the recommended installers on the Haskell front page is that they are made by power users who simply lack the perspective to understand the requirements of new users.

To be clear, the current recommendations that highlight minimal installers were not made on behalf of “power users.” In fact, they were motivated by those with the most experience helping _new users_. As the discussed on various reddit threads [1], people coming to Haskell in the context of independent acquisition (i.e. not students at the fine institutions of higher learning with sufficient distinction and taste to teach Haskell) have consistently had trouble with the platform. I am here talking about people that are probably experienced programmers to some degree, but just not experienced with Haskell. If they are to be confused by things, I want them to be confused by clever types, subtle uses of laziness, and mind-blowing idioms relying on higher order functions, not confusing messages when trying to install libraries. The first things they try to do are not write student exercises, but e.g. install Yesod, or GHCJS, or Yesod and then GHCJS, and then some package with an API binding for some webservice which has not been updated in two years and requires an old version of time, and then maybe a GUI toolkit and of course lens. They do not yet know how to vet packages and carefully manage dependencies. They do not know how to fix trivial breakages or manually change bounds. They know how to type at least three words: “cabal” “install” and “ghci”. And they do not have a professor or instructor to guide them. And, consistently, repeatedly, they destroy their package environment. And when they do so, the answer is invariably the only one that is easy to give remotely and without lots of context — wipe the package environment and start again. The most important message for these new users is “always use a sandbox”, because that at least keeps them from destroying the full environment when they allow installations of packages that break other packages, etc. And the platform, to the extent that it changes and complicates build plans, does these users no good.

A minimal installer followed by half an hour of cabal install is an extremely bad way to  sell Haskell to a newcomer. Sure, it is more flexible, but flexible is *bad* for newcomers. 

I will grant this. But I will also say that a full platform install followed by a day of trying and failing to install complex combinations of dependencies also isn’t particularly inviting. Again, I very much _want_ to be able to recommend the platform unilaterally as the “best choice nearly always”. I like the fact that it has a uniform process for releases and installers. I like that it has infrastructure and buy-in, and I remember how bad things were in the days before it. I personally always use it, and I personally (absent the network/windows issue that MinGHC solves) don’t understand why experienced users don’t always go with the platform (except, I suppose, if they are so accustomed to “sandbox everything” that they never see a payoff, or if they are now using nix, which is also an awesome approach but very much for power users still). I think Duncan’s proposals are very good. That is to say first, change the “new sandbox behavior” issue. Once we do that, the platform will be perfectly fine for the sorts of users I described above, and I would hope that changing the recommendations on the website to say so would be uncontroversial. Then, above and beyond that, and at a future date, finishing the big plans for nix-like operations, allowing the same version of package A to be built against multiple versions of package B, etc, will do away for the need for sandboxes altogether, we hope. In the interim, I did point out an outstanding ticket [2] on the homepage to further improve and balance the current layout and wording — pull requests are always welcome!  Cheers, Gershom [1] a) Most recently, related to this discussion and linked by acowley: http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/ b) Occasioned by the launch of the new homepage: http://www.reddit.com/r/haskell/comments/2w3php/venerable_haskell_platform_n... [2] https://github.com/haskell-infra/hl/issues/55

A minimal installer followed by half an hour of cabal install is an extremely bad way to sell Haskell to a newcomer. Sure, it is more flexible, but flexible is *bad* for newcomers.

We are using Haskell in a few courses here at UNSW. We always recommend students to use the Haskell Platform when they want to install Haskell on their own machines. It’s one download and gives them the same packages on all platforms. Anything else just leads to lots of support questions of students trying to get their installations working to do their assignments.

Manuel

...

One of the points of argument was that some people were arguing that the minimal installers are better for new users. I disagree, but certainly there is one issue that could be fixed that'd go a long way to resolving the particular use case with new users that was raised.

...

The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new features and development have clearly changed the landscape for use to reconsider what to do.

...

I don't think the status quo for the Platform is now viable - mostly as evidenced by waning interest in maintaining it. I offer several ways we could proceed:

Well, the people who like it don't really complain. But yes, things need improving.

...

*1) Abandon the Platform.* GHC is release in source and binary form. Other package various installers, with more or less things, for various OSes.

*2) Slim the Platform.* Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell.

*3) Re-conceive the Platform.* Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction.

I'm not sure that slimming is really needed. But I agree with the GPS approach. The current set is too small in the sense that it doesn't cover lots of things people need, and the GPS approach should solve that. We don't need to promise such high QA for the extended set, we just need to make sure they build together.

We need to remember that one of the purposes of the platform as originally conceived is to get people to sync on the versions of their deps that they're using at the moment. This is where the GPS approach shines, but it still makes sense to have some core set at the middle of that. It's true that advanced users don't need lots of things pre-installed, but they sill benefit from other developers synchronising on versions of deps, so that they can have more things work together more often.

On the argument that the platform is too big, the primary issue there is that people want to make new sandboxes that are more minimal, and with cabal's current behaviour of basing all sandboxes off of the global package db, and the platform installing lots of packages globally then we get a conflict.

But the solution is simple: make cabal sandboxes not be based off of everything that is globally installed, make new sandboxes be really minimal (though the ghc/platform installers could help with identifying what is the minimal subset).

Duncan

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On March 25, 2015 at 12:43:22 AM, Manuel M T Chakravarty (chak@cse.unsw.edu.au) wrote:

Look. I guess, I count as a power user ;) I rarely use sandboxes. They are great for a particular type of use, but you can do many things quite happily without them. (Ask SimonPJ; I reckon he doesn’t use sandboxes either.)

Ironically, the only time I have had to use a sandbox was in doing work on the new Haskell homepage (it is written in Yesod). In fact, that was insufficient for some reason and I had to install hsenv as well and use that for an even “stronger” sandbox. As I have said, I also install the platform whenever possible. Believe me, you are preaching to the choir!

The mistake here is to try to make this a one-size-fits all. I honestly don’t care about a platform that is ideal for everybody. I want something that I can point newbies at that makes them happy quickly. That needs to be one download with all the packages that you need to get going included. .. Well, we have got people who want to learn Haskell now and who use Haskell as part of their  coursework now. Why make them wait for future work which will probably take longer than  planned, needs to be rolled out, etc?

I do not understand this. The platform still exists, is still great, is not going anywhere, and as far as I can tell, is on track to become even better. You can point people at https://www.haskell.org/platform/ or you can point them at downloads.haskell.org which links to there or you can point them at www.haskell.org and tell them “the downloads page gives you options, pick the platform option.” Nobody who wants to use the platform must wait for anything. Nobody has taken anything from you, or anyone else. Nobody wants to take anything from you, or anyone else. We just want to recognize that this other set of users — those coming from other languages, and wanting to “from the gate” install large sets of dependencies — this set of users has grown and is growing and if we don’t want them to become frustrated and bounce off Haskell, then we need to provide resources for them too, and steer them to things that meet _their_ needs as well. They are not lucky enough to be in your class and be guided by an instructor. If you want to patch the downloads page so that it more clearly highlights the platform option or makes clear that if you want to be a “power user” and manage lots of dependencies with abandon you may want the minimal installers, and if you want “a good, wide-ranging set of defaults to experiment and learn with” then you want the platform, or some other wording that is perhaps clearer, or anything at all like that, then there is again a ticket on the github homepage to improve the language, and pull requests are welcome. The compromise wording on the page now is just that: a compromise. I don’t even claim it to be a great one, just what was settled on. If you (or anyone) can improve it to present both sorts of installers and the tradeoffs more clearly and more simply, please do! There are different types of beginners, and meeting all their needs (as well as the needs of long-timers of various stripes, etc) all at once is a tricky task. Again, the main advantage that students have is that they have instructors who can guide them in what they recommend to download, how to get started, etc. So, for the moment, I would argue that students are not the most fundamental target audience for that snippet of text on the downloads page. But, that does not mean the language cannot be better for students too. And I would very much like it to be! Beyond that I don’t feel we’re discussing anything as metaphysical as flexibility or simplicity. And I don’t feel my own preferences are necessarily better or worse than others — I just want two things, as do we all I think. A) To have the best possible toolsets available for all types of users in all possible development setups, and B) To somehow condense the core of that information into an easily digestible form to help steer visitors to the Haskell homepage to the setup that is right for _them_.  As always, anybody who wants to help with this in any regard with the new homepage is welcome and invited to do so. We have plenty of open tickets and room for improvement all around, a helpful crew on the #haskell-infrastructure irc, and patches, pull requests, and new tickets are always welcomed. Best, Gershom

On Tue, Mar 24, 2015 at 10:09 PM, Gershom B wrote:

...

There are different types of beginners, and meeting all their needs (as well as the needs of long-timers of various stripes, etc) all at once is a

Actually, pretty much all other language systems (C++, Java(*), Python, PHP, Ruby, Scala, etc...) meet all users' needs, not just beginners, with one common tool set + core libs. Different users don't install different

At minimum it should also have cabal-install, and the libs so many things are built on: async, mtl, text, parsec, vector, etc..., and also common tools (like happy, alex, and hscolour). You can argue plus or minus some of

On Wed, Mar 25, 2015 at 1:21 AM, Mark Lentczner wrote: tricky task. packagings of Python. There isn't a list of choices of Scala installers. My first reaction was "no, that's not right". Then I realized that it is - but only if the "common tool set" includes some kind of package search and installation tool. Which leads directly to: these, the set could be bigger or smaller, ... basically, it should be the Platform. You have just defined the minimum platform. ghc, cabal-install, and the things needed for those. I think we also need better documentation than the current platform has. Go back to the case of moving beyond textbook exercises, which can tell you what packages to use, to trying to solve your own problems, no matter what they are. You will eventually wind up asking "What's the function/library/package to do X?". The documentation should guide users to the packages in the install, whether it's called "the Haskell Platform" or "ghc". I'm not qualified to pick the libraries. I'm not sure any one person is, or can be. But I can certainly help write documentation or tutorials for using them once they've been picked, and would be more than happy to do that.

Yes, I'm arguing that the GHC release and the Platform release should be one and the same. The vast majority of the pain I think stems from the skew between these two, and that GHC is not enough. You need something besides the GHC release. If that something isn't standard, and/or it lags the GHC release, then all the attendant problems creep in. Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: · There are some people working on GHC itself. That is already a big job. Just getting GHC ready to release is hard. Hence the desire that Herbert mentions to strip it down as much as possible. · But a release of GHC is not adequate. No one except power users should install a GHC release. It should be a secret among the cognoscenti that a GHC release has happened. · The first sensible unit of installation (at least for a non-power user) is the Haskell Platform. It includes the tools you need (Happy, Alex, Cabal) as well as a small but useful collection of libraries. That’s why GHC’s download page explicitly says “Stop! Shouldn’t you be installing the Haskell Platform instead?”. · HP releases should therefore, in contrast to GHC releases, be widely publicised. · Moreover, a HP release should very closely follow a GHC release (though the former could occur more often), to reduce the chance that a naïve user bypasses the HP and gets GHC alone. That is what Mark is rightly working on at this very moment for GHC 7.10. We probably should work harder to reduce the lag. In this sense, the plan was always that “the GHC and the Platform release are one and the same”. I think of the HP release as the “real GHC release”. It’s just that, as an implementation mechanism, the GHC team push out the bare GHC bits, so that the HP team have something firm to chew on. So that was the plan. I still think it’s a good plan. But it clearly is not working well, and I’m hazy about why. Possible reasons: · Possible diagnosis 1. Installing HP somehow screws up the world for power users, or for a beginner who grows into a power user. Surely we can fix this! Installing HP should not get in the way. I suppose that, even if installing HP doesn’t get in the way, it might be a waste of internet bandwidth and disk space for some power users. But that is a smaller problem. · Possible diagnosis 2. We have not shared the plan as a community; that is, we have focused lots of attention on GHC releases, and little attention on HP releases. It should be the other way around. So here are the questions in my mind: · Is the original plan still good? · Is it possible to make the HP so that installing it does not get in the way of power users? So that installing it is, at worst, a waste of disk space? Personally I like the plan because it’s simple; because it usefully empowers, and splits responsibility between, two different groups (GHC and HP); and because it makes life easy for our users. Simon From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of Mark Lentczner Sent: 25 March 2015 06:22 To: Gershom B Cc: Manuel M T Chakravarty; haskell-platform@projects.haskell.org; haskell-infrastructure@community.galois.com; Duncan Coutts; ghc-devs@haskell.org; Haskell Libraries Subject: Re: wither the Platform On Tue, Mar 24, 2015 at 10:09 PM, Gershom B mailto:gershomb@gmail.com> wrote: There are different types of beginners, and meeting all their needs (as well as the needs of long-timers of various stripes, etc) all at once is a tricky task. Actually, pretty much all other language systems (C++, Java(*), Python, PHP, Ruby, Scala, etc...) meet all users' needs, not just beginners, with one common tool set + core libs. Different users don't install different packagings of Python. There isn't a list of choices of Scala installers. I had a really long post prepared about my reasoning, but I think I'll just spare you all, and cut to the chase: The problem is how GHC is released: It is released as a compiler, and minimal base libs, and (strangely) with 1/2 of cabal, haddock, ghc-pkg, no other tools, and no installer. This is an insufficient set of things for most users. At minimum it should also have cabal-install, and the libs so many things are built on: async, mtl, text, parsec, vector, etc..., and also common tools (like happy, alex, and hscolour). You can argue plus or minus some of these, the set could be bigger or smaller, ... basically, it should be the Platform. We should consider those additional libs as frozen, and tied to the GHC release, as the base libs - because that will mean those will be the common versions people will build and test against. And they will update as frequently as GHC. (If they aren't as stable as all that, or aren't willing to be part of that release cycle and constraint, then perhaps they shouldn't be in that set!) Yes, I'm arguing that the GHC release and the Platform release should be one and the same. The vast majority of the pain I think stems from the skew between these two, and that GHC is not enough. You need something besides the GHC release. If that something isn't standard, and/or it lags the GHC release, then all the attendant problems creep in. We worked really hard last Summer to make the Platform be very quickly buildable - there is already a 7.10 RC3 Platform out (though I did it by, ahem, not following Haskell Platform procedure - and, er, well, just did it!) - I think we should just pare back the definition of the Platform, and then commit to making it be the way new GHCs are released. - Mark (*) Okay, so Java comes in three variants, but they are mostly distinguished by final deployment environment, not user type.

Thanks for linking to that Mike, I'd actually forgotten that I'd written that :). Those are all very concrete issues people run into with the platform regularly, but I'd like to point out a meta issue: the platform tries to do too much, and in a non-composable manner. As I pointed out previously, it's providing a tools installer, choosing blessed libraries, pegging certain library versions, and selecting a distribution manner for those libraries. Even if the other issues were all addressed, I still believe the current trajectory of the platform is problematic, because it is necessarily removing choice. When Mark, Duncan and I were discussing GPS Haskell at ICFP, a big goal (in my mind at least) was to allow individual tools to target individual goals. I don't expect every use case to be served by a curated package set (like LTS), so making that an optional feature of tooling makes sense. Similarly, almost all users (excepting some people playing with bleeding-edge GHC) will benefit from having an easy-to-use GHC+cabal-install installation, but a large set of users (specifically Hackage package authors) need a way to compile against different versions than the HP-blessed ones for testing purposes. And now a completely separate point: the current functioning of the HP process seems very much at odds with the way people actually write and release packages. Some examples: * Having to go through an extra step of requesting that a package version is bumped is tedious, and resulted in a buggy attoparsec being released in HP * Requiring package authors to endure long debate periods before the package is accepted scares people off from wanting to participate * A number of months back, the HP was used as a vehicle to push the PVP agenda as well, which completely alienated some people from wanting to participate (ironically, the package being pushed instead was not PVP compliant either, go figure). The practical result to that is we currently have no plans at all for getting TLS/HTTPS support into the platform, and everyone's tooling (cabal-install) is far less secure than it should be. * Authors want the freedom to quickly release new versions to their users, especially for bug fixes. While in theory the HP is set up to do bugfix releases, in practice this has never happened. In that sense, it is often preferable from the eyes of a package author *not* to have his/her package in the HP, as then users are better served As long as I'm writing a long email, I want to point out one other thing. A lot of the points being raised in this thread are discussing an idealized view of what the HP could become. I'm fully in favor of improving it (like I said, that's why I tried working with Mark on GPS Haskell and integrating with Stackage). However, we need to accept the reality of the situation today. Could the windows HP installer be improved like MinGHC to include MSYS? Absolutely, and I hope it happens. Could we improve Cabal and work around the global package database issues we've been mentioning? Yes, and I support such moves. But we need to acknowledge current deficiencies, and plot out a course of action to solve them. And given that this thread started by lamenting how much effort the platform currently takes to maintain, I'm concerned about those improvements actually occurring. On Wed, Mar 25, 2015 at 11:30 AM Mike Meyer wrote:

On Wed, Mar 25, 2015 at 4:09 AM, Simon Peyton Jones

...

wrote:

...

So that was the plan. I still think it’s a good plan. But it clearly is not working well, and I’m hazy about why. Possible reasons:

Possibly relevant is the stackage commentary on HP at http://www.stackage.org/install#why-not-haskell-platform:

• On Windows, it does not provide a complete environment (missing MSYS). • By placing a large number of packages in the global package database, Haskell Platform installations are more easily corrupted. • The choice of package versions conflicts with the needs of many commonly used packages. • Some of the package versions included with the platform have known and severe bugs, and cannot be reliably upgraded. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On 2015-03-25 at 10:52:20 +0100, Simon Peyton Jones wrote: [...]

...

• Some of the package versions included with the platform have known and severe bugs, and cannot be reliably upgraded.

[...]

I guess the solution is to release a new version of HP.

IMHO, if HP releases are to happen more frequently, a simple way to upgrade would be desirable rather than having to download a new multi-MiB full installer image each time only because a single package was updated (and the ability to have access to multiple HP releases side-by-side -- in case that isn't supported already) Or put differently, how shall HP users be informed they're not running the latest HP version with all known critical bugs fixed? Cheers, hvr

Simon Peyton Jones wrote

My question was: can they be fixed so that HP does not get in the way? E.g. if we solve the multiple-versions-of-packages problem with Cabal (which Duncan in a separate thread says we can), then that would solve the first two; and for the third, I guess the solution is to release a new version of HP.

Or we could follow what Microsoft have done to solve this problem with .NET, and move non-GHC packages out of the platform into a separate delivery vehicle - which could be bundled with the platform if desired. As it stands, the platform cannot simply update packages without a full install. This is the essence of our problem - update the platform libraries independently of a GHC/platform release. (In the same way that you can upgrade the packages which were installed with a specific version of a Linux distro, or use NuGet to upgrade packages that were released with a .NET platform.) -- View this message in context: http://haskell.1045720.n5.nabble.com/wither-the-Platform-tp5767291p5767634.h... Sent from the Haskell - Libraries mailing list archive at Nabble.com.

On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones wrote:

Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: ...

I still like that plan! Concrete proposal based on that and the other fine input in the responses: *Simultaneous Release:* Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in "RC" until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go "release" in the same announcement. *In fact, let's version HP with the same number as GHC!* *Pare the Platform Back:* Bring down the number of packages in the Platform, focusing on the things that everyone needs, like text and vector, etc. I reckon that about 1/3 of the packages should go. *And, make that stuff be the latest it can be at each release. *The OpenGL stuff is a hard one, since it is large, but a very big painful build if you need it. Perhaps we need server/non-server versions of the platform - but only if we can get them out on the same day. *Make sure the Platform Installers are Complete:* I don't know Windows, but if this means adding MSYS, great.. let's do it. The Mac installer has a version switching script and supports multiple installed versions already, but people didn't seem to know. There needs to be more documentation. *Make Updating the Packages in Cabal 'work':* I'm unclear on the right technical path here, but we need away for Cabal to understand that a) it can't update the stuff tied to GHC, b) it *can* update the other stuff installed from the platform, but as a cohesive set, c) it can easily (and optionally) do (b) in just a sandbox, or in the global(-ish) install. *One Web Site:* Drop the separate Platform website. Incorporate it into the lovely new Haskell one. Put all the documentation there. This certainly has implications for how we choose what is in the platform, and how we position those packages. In particular, packages in the past have been stuck at older versions because of the requirement that the transitive dependencies be added to the platform, with the support guarantee that implies. I think we'd have to change that: There are packages in the platform, like attoparsec, packages that are there because they are dependencies, like scientific, but who knows if they will be there next time! Now, normally I'm the crazy, ranty stability guy. But, I'm thinking this: It is better to have clear release points that package developers can test against, then to have the current slidey scale of different stability guarntees, on different release schedules that we have now. And, to be honest, I realize that the Haskell community "hath spoken" recently on the issue and prefers things to evolve even if the APIs change... I think we can do this if all the great volunteer talent in our community steps up. Shall we? — Mark

In general, I think Mark's proposals are the way to go. However, I know that there are many developers who will chafe under this plan. There is an inherent tension between "latest and greatest" and "batteries included." While I understand the concerns of those who are on the bleeding edge, I believe it is best for the future of Haskell to go in Mark's direction. Issues that will need to be confronted: 1. Slower release cycle: Coordinating the stability of even a streamlined Platform with a new GHC release candidate will take more time. On the other hand, this is likely to produce a more tested final GHC release. 2. Less diversity in new GHC features: The GHC developers have generally aimed new features at a future release, where the existence and stability of new features has driven their incorporation. It was assumed that the Platform would eventually catch up. If the GHC release and the corresponding Platform release are simultaneous, then some GHC features may need to be pushed out to the following release so there is time for the Platform to be adapted. 3. The GHC development process will need to become more phased: Experimentation with new features will still be encouraged, but adoption of the new features will need to be gated to correspond with what the Platform can implement. (This is really another view of issue 2.) So I would like to add to Mark's call for the developer community to "step up": The research community will need to accept a more structured deployment of their innovations. Howard ________________________________ From: Mark Lentczner Sent: Wednesday, March 25, 2015 7:24 AM Subject: Re: wither the Platform On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones wrote: Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: ... I still like that plan! Concrete proposal based on that and the other fine input in the responses: Simultaneous Release: Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in "RC" until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go "release" in the same announcement. In fact, let's version HP with the same number as GHC!

Pare the Platform Back: Bring down the number of packages in the Platform, focusing on the things that everyone needs, like text and vector, etc. I reckon that about 1/3 of the packages should go. And, make that stuff be the latest it can be at each release. The OpenGL stuff is a hard one, since it is large, but a very big painful build if you need it. Perhaps we need server/non-server versions of the platform - but only if we can get them out on the same day.

Make sure the Platform Installers are Complete: I don't know Windows, but if this means adding MSYS, great.. let's do it. The Mac installer has a version switching script and supports multiple installed versions already, but people didn't seem to know. There needs to be more documentation.

Make Updating the Packages in Cabal 'work': I'm unclear on the right technical path here, but we need away for Cabal to understand that a) it can't update the stuff tied to GHC, b) it *can* update the other stuff installed from the platform, but as a cohesive set, c) it can easily (and optionally) do (b) in just a sandbox, or in the global(-ish) install.

One Web Site: Drop the separate Platform website. Incorporate it into the lovely new Haskell one. Put all the documentation there.

This certainly has implications for how we choose what is in the platform, and how we position those packages. In particular, packages in the past have been stuck at older versions because of the requirement that the transitive dependencies be added to the platform, with the support guarantee that implies. I think we'd have to change that: There are packages in the platform, like attoparsec, packages that are there because they are dependencies, like scientific, but who knows if they will be there next time! Now, normally I'm the crazy, ranty stability guy. But, I'm thinking this: It is better to have clear release points that package developers can test against, then to have the current slidey scale of different stability guarntees, on different release schedules that we have now. And, to be honest, I realize that the Haskell community "hath spoken" recently on the issue and prefers things to evolve even if the APIs change... I think we can do this if all the great volunteer talent in our community steps up. Shall we? — Mark _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Good plan. You didn’t mention a key point: · Make sure that installing the Platform doesn’t get in the way, if you subsequently want to upgrade libraries or whatever. I am un-clear about precisely what the problem(s) is/are here. I’m pretty sure they require infrastructure work (in Cabal) to achieve. Simon From: Mark Lentczner [mailto:mark.lentczner@gmail.com] Sent: 25 March 2015 14:25 To: Simon Peyton Jones Cc: Gershom B; Manuel M T Chakravarty; haskell-platform@projects.haskell.org; haskell-infrastructure@community.galois.com; Duncan Coutts; ghc-devs@haskell.org; Haskell Libraries Subject: Re: wither the Platform On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: ... I still like that plan! Concrete proposal based on that and the other fine input in the responses: Simultaneous Release: Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in "RC" until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go "release" in the same announcement. In fact, let's version HP with the same number as GHC! Pare the Platform Back: Bring down the number of packages in the Platform, focusing on the things that everyone needs, like text and vector, etc. I reckon that about 1/3 of the packages should go. And, make that stuff be the latest it can be at each release. The OpenGL stuff is a hard one, since it is large, but a very big painful build if you need it. Perhaps we need server/non-server versions of the platform - but only if we can get them out on the same day. Make sure the Platform Installers are Complete: I don't know Windows, but if this means adding MSYS, great.. let's do it. The Mac installer has a version switching script and supports multiple installed versions already, but people didn't seem to know. There needs to be more documentation. Make Updating the Packages in Cabal 'work': I'm unclear on the right technical path here, but we need away for Cabal to understand that a) it can't update the stuff tied to GHC, b) it *can* update the other stuff installed from the platform, but as a cohesive set, c) it can easily (and optionally) do (b) in just a sandbox, or in the global(-ish) install. One Web Site: Drop the separate Platform website. Incorporate it into the lovely new Haskell one. Put all the documentation there. This certainly has implications for how we choose what is in the platform, and how we position those packages. In particular, packages in the past have been stuck at older versions because of the requirement that the transitive dependencies be added to the platform, with the support guarantee that implies. I think we'd have to change that: There are packages in the platform, like attoparsec, packages that are there because they are dependencies, like scientific, but who knows if they will be there next time! Now, normally I'm the crazy, ranty stability guy. But, I'm thinking this: It is better to have clear release points that package developers can test against, then to have the current slidey scale of different stability guarntees, on different release schedules that we have now. And, to be honest, I realize that the Haskell community "hath spoken" recently on the issue and prefers things to evolve even if the APIs change... I think we can do this if all the great volunteer talent in our community steps up. Shall we? — Mark

On Fri, Mar 27, 2015 at 5:24 AM, Herbert Valerio Riedel wrote:

I'm a bit worried about the aspect of delaying the GHC release schedule for the sole purpose to provide the HP with more visibility,

That isn't the purpose at all. My aim ins't to promote HP. The aim of my suggestion is to ensure that there is a consistent way for the community to "get Haskell" (as GHC itself is not enough for anyone - you need cabal at the least, and there are libraries that are common enough to be considered essential: text, vector, etc...). It is also to ensure there is a consistent reference point for package developers to test their packages against, for those packages that wish to support more than just the current GHC. Again, GHC releases themselves do not form a big enough reference point to ensure two packages that "support the last two release" are supporting the same thing. ...

Otoh, there's usually enough time between the last RC and the actual final release, which should give the HP at least one week of time anyway w/o any active delay on GHC's end.

Well - if there is a week of commits to GHC, it should really do another RC before declaring it final. The difference between the last RC and the release should a single commit of no more than the version number change and the change log. Frankly, if we are all on board with this, then GHC could suffer a few day (week at most) delay between such an RC (as in "we're frozen, save for the version stamp"), and announcing "release". This would not only allow there to be a Platform on the same day - but also GHC bindists for other OSes on the same day.

Otoh, as soon as the new HP is released, it provides users with the perception of a new stable HP release to jump on right-away. That, however, may lead to a poor experience if the it's the first HP release for a given major GHC version as Hackage usually hasn't fully caught up by the time a GHC x.y.1 is unleashed.

We need to have to maintainers of the packages in the HP on board with this and down with the "we're all going to gear up in the four weeks before a GHC version"... not "we'll gear up in the four weeks after". Frankly, for the kinds of packages that are in the platform (text, vector, unordered containers, etc...), having these packages lag GHC release so that they are broken on Hackage the day of GHC release is in nobody's interest: It gives a poor experience for ALL users of Haskell. So if we had co-released a HP

featuring GHC 7.10.1 today, there would still be enough Hackage packages not yet compatible with GHC 7.10.1 to recommend users *not* to install the release right-away.

But that is true of GHC as well. We need to stop having the attitude of "Platform is for newcomers / GHC is for heavyweights". It is perfectly fine to announce "GHC 7.10.1 is out - you can install it from Platform 7.10.1 which is a complete installer for your OS with core and standard libraries, and tools; or if you prefer you can get the minimal binary compiler build. As always, not all packages on Hackage will be compatible." Then our recommendations on to users on IRC are about which version is best for their needs, not "don't install platform, you won't be able to get lens to compile..."

So I'm actually not sure if a simultaneous release of GHC x.y.1 w/ HP would be in the HP's best interest in terms of providing a reliable and complete development environment (which IMO requires access to Hackage, even more so if the HP is to be reduced to contain less packages)

People who care about stability will go ahead and hang back to what they consider a stable reference for them. (Gosh, how many projects are still supporting Python 2.6?!). But it will only be a "stable reference" if people use it, and package maintainers support it. Today's mess of GHC releases, Platform releases, alternative installer releases, etc... leaves both users and package maintainers no way to create or find stability. - Mark

On Fri, Mar 27, 2015 at 7:27 AM, Edward Kmett wrote:

The lens package (alongside every other package I maintain that is incurred as a dependency of lens) has very

deliberately support all Haskell Platform releases for at least 3 current

major GHC releases, often at great expense to the API.

No offense, but I don't think lens is the culprit here.

Excellent! None taken. I appologize for my poor choice of example. Several people have included lens in an example of "newcomers want to install x, y, and z - and it won't work with the platform." It is great that lens is not the problem - but it does underscore that the other packages haven't seen fit to match the same stability release points as lens - hence the unlikeliness of them working together except at HEAD.

On 2015-03-25 at 05:43:13 +0100, Manuel M T Chakravarty wrote: [...]

...

The most important message for these new users is “always use a sandbox”, because that at least keeps them from destroying the full environment when they allow installations of packages that break other packages, etc. And the platform, to the extent that it changes and complicates build plans, does these users no good.

You are talking about a specific kind of new users. These new users want to install a web stack or similar — i.e., they need tons of packages. These people may be new to Haskell, but I reckon they are otherwise power users.

I’m talking about somebody picking up Learn you a Haskell and wanting to write Hello World.

IMO, that class of users don't need anything beyond the packages bundled with GHC anyway... However, LYAH already directs such users to the platform as it states in its introduction: | What you need to dive in | | A text editor and a Haskell compiler. You probably already have your | favorite text editor installed so we won't waste time on that. For the | purposes of this tutorial we'll be using GHC, the most widely used | Haskell compiler. | | *The best way to get started is to download the Haskell Platform,* | which is basically Haskell with batteries included.* | [...] And here's what Bird's "Thinking Functionally with Haskell" has to say about the HP: | 1.5 The Haskell Platform | | If you visit the site www.haskell.org, you will see how to download | The Haskell Platform. This is a large collection of tools and packages | that can be used to run Haskell scripts. The platform comes in three | versions, one for each of Windows, Mac and Linux. We deal only with | the Windows version, the others being similar. So I'm not too worried that newcomers following a guided course/tutorial (such as LYAH or TFwH) won't be directed to the platform. Cheers, hvr

On Tue, Mar 24, 2015 at 8:20 PM, Gershom B wrote:

install Yesod, or GHCJS, or Yesod and then GHCJS, and then some package with an API binding for some webservice which has not been updated in two years and requires an old version of time, and then maybe a GUI toolkit and of course lens.

That sounds like a recipe for Cabal Hell, Platform or not!