Proposal: Elm should support Stack and be on stackage

[eeue56]

At the moment Elm has a few ways of being installed, but none which seem completely reliable . I've had a few issues with students installing either on platforms without binary support, like 32 bit Linux, or where the buildscript failed on their version of ghc/cabal. This is partly down to Haskell's package management issue - but stack seems like it will answer a lot of these problems. It should also remove a lot of work the current install script does, like creating sandboxes etc.

stack is also a platform agnostic solution to the issue, unlike adding packages for Arch or any particular distribution's repos.

Thoughts on this?

[evancz]

I think it'd be better to just fix the npm thing for elm-reactor. It has been frustrating that the maintainer there has not fixed the ELM_HOME thing, but it mostly works.

Before getting into more Haskell crap, I'd like to actually be clear about which platforms have issues. Right now there are Windows and Mac installers that work well every time. I make those. There is an npm installer that, with the next release will support Windows, Mac, and any unix that can run a Debian binary. Generally speaking, I don't want typical users building from source, regardless of how "easy" we can make that.

I have heard folks on Arch and Nix having issues that I'm not sure can be solved once the npm thing is fixed.

What exact linux distributions are you concerned about?

[eeue56]

I have heard folks on Arch and Nix having issues that I'm not sure can be solved once the npm thing is fixed.

Most the Linux problems I've encountered are to do with people having installed the Haskell tools from their package manager, which for various reasons didn't play nice with Elm. Two particular cases today were on Ubuntu 32 bit (due to the lack of a npm binary for 32 bit). I had to guide these users through completely reinstalling Haskell and cabal - but this is a mess up on the Haskell side of things, more than Elm. The appeal behind moving to stack would be the ability to just get a valid version of ghc and a packaged Elm that compiled correctly with that version, along with all the deps needed. That would remove the "cabal hell" step that I've helped people through a few times now, when they haven't done enough Haskell to have encountered it before.

The same problem can exist on any Linux distro where the package manager doesn't work nicely with cabal or the maintainers for ghc/haskell-platform don't keep things up to date with the tools needed for Elm. I've had it on both Arch and Fedora, but the most problems I see seem to be from Ubuntu users. Another particular appeal of stack is the platform agnostic soltuion here - if you have stack, then you don't need to care about the distro's particular versions of things.

My particular need is to enable users to install and getting using Elm without feeling overwhelmed or doing anything too involved. Right now, it seems like share-elm.com is the closest to that, which largely works for the moment. There's been some people who were just put off completely by the install step not working for them, which is a real shame.

[evancz]

So I am reading about two specific cases, both on a 32 bit version of Ubuntu.

The root issue there is that the maintainers of the npm thing built only for 64. For windows and mac I always build on 32 bit so we don't have this problem. Again, I am going to resolve that in the next release.

I don't think anyone should have to build from source, if that's happening, the failure is elsewhere.

Are there concrete cases you know besides 32-bit builds of Ubuntu?

cc @passy and @kevva to show what folks are currently running into.

[evancz]

Another approach is probably just to use exact dependencies in all the core things.

I generally don't trust any of this Haskell stuff anymore. The folks who break my stuff the most with hackage and cabal are also the people making stackage and stack. I don't super trust them at this point, so I want the rest of the community to sort out "the new right thing" before doing a bunch of work to figure out if these new tools are actually good. Sandboxes were the cool new thing recently, but that still does not work. I don't want to be in an endless cycle of people having a bad experience building from source when the real solution is that no one should be building from source.

[jvoigtlaender]

If I may chime in:

• Getting npm to work on all setups is great, but doesn't help people who do not only want to use Elm but also help with development of Elm tools, so have to build the compiler and packages site and so on locally on their machine. So some people will always have to build from source, though not the target group @eeue56 is concerned about here.
• For people having to build from source, I'd really like to see whether simply doing what I suggested here would solve problems. It is essentially the "use exact dependencies" strategy, but it is not you who has to find out which set of exact versions will work. Instead, it is kind of crowd-sourced and continuous-integration-tested. Also, no new tools are involved on the developer's side. One can simply take the result of their testing, as a big assignment of versions to packages, and drop it in as a configuration file which Cabal will automatically use.

Meta: The observation, if I read that correctly, "the people who make Stackage do release packages on Hackage that often break my stuff" may be true. But the point, I think, is that they themselves rely on the Stackage overlay above Hackage. So if one adopts that flow, one won't get those problems. Seeing Hackage as a big sea of packages, and Stackage as a curated and guaranteed-to-work-together subset, it's maybe no surprise if one runs into problems when not making use of the curation work and instead just taking in the uncurated big sea of packages in raw form.

[eeue56]

Are there concrete cases you know besides 32-bit builds of Ubuntu?

The last one I remember was someone on Ubuntu 64 bit following the Seven More Languages in Seven Weeks book. I can't remember the exact details of it, but they ran into cabal hell while installing too. I'll note any further encounters I have and see if there's some pattern. I guess the problem with the 32 bit issues could be solved by using a buildbot for releases, meaning no manual builds any more. Is there any blockers to using buildbot, other than resources?

I don't think anyone should have to build from source, if that's happening, the failure is elsewhere.

This is a good ideal to have, and if feasible then great, that's exactly what I need here.

. It is essentially the "use exact dependencies" strategy, but it is not you who has to find out which set of exact versions will work. Instead, it is kind of crowd-sourced and continuous-integration-tested.

This is a large part of the stack appeal to me. I'm not going to disagree that the state of Haskell's packages and package management is a mess, but stack is definitely a step in the right direction. It's a shame that so many Haskell tools are a pain to install. Idris has the same problem to some extent. Tidal too, though tidal has added stack support.

[eeue56]

Perhaps the solution here is to instead measure how many people have issues installing. There will be some form of stats, through the number of people that post problems with installing. The main problem with that is the fact that a lot of people will just give up if they encounter a problem like cabal hell. I don't know if there's any sensible way to collect details from that category of user though.

[garyLockyer]

For Ubuntu 15.04 the issues seem to be having Haskell Platform installed. When I removed this and installed GHC, install from source worked. Currently I've unstalled the Ubuntu GHC and Haskell platform packages, and installed GHC from stack. Which works on a new build, but sometimes fails when rerunning over an existing build.

[eeue56]

Yes; unfortunately it's been a known issue for a very long time and been the main cause of long-term Haskell issues among Ubuntu users setting up with existing Haskell projects.

[evancz]

I am in the process of closing this repo down as a failed experiment, so I think it makes the most sense to move this to elm-platform.

The key question is "which platforms should be supported by the platform?"

I think the best route to make progress here is to organize data on the following questions:

• How many programmers use different distributions?
• Which distributions currently have installation issues?

Ideally this can be done as a github table. (Ubuntu 32-bit = problems, Ubuntu 64-bit = no problems, etc.)

Once we have this, we can explore the 4 or so different ways of releasing haskell code through some package system. Again, I feel like this is a bad idea. The point is to make the users life easy above all else. If "the typical build process" for Ubuntu or Arch involves setting up GHC in any way, I think we are not serving the users well. Install should take 5 seconds like it does on Mac or Windows, and I don't want to help achieve a worse outcome for no reason.

Point is: yes, there are ways to package Haskell code, but lets figure out who we are serving and what they need exactly before we get lost in these details.