Tracking installation issues

[evancz]

This is a meta issue to track installation struggles. If you have potentially relevant info, open a separate issue. Do not use comments for this. Opening a separate issue helps us organize things better.

The current state of affairs (as far as we know) is like this:

route	OS	Version	bits	status
installer	Windows	*	*	✓
	OSX	*	*	✓
npm	*	*	*	kevva/elm-bin#22
	debian variants	*	32	binary is 64-bit
	other linux	*	*	?
from source	*	*	*	cabal hell

Based on website traffic, we can roughly guess that 50% of users are on OSX, 30% are on windows, and 20% are on some flavor of Linux.

Folks with struggles: 20%

Reporting a New Issue

If you are having issues that are not captured by this table, please open a separate issue that states:

• Your OS with the version number
• Number of bits
• Your installation method
• The error encountered

For example,

• OS: Ubuntu 13.04
• bits: 32
• route: BuildFromSource.hs
• error: ENOENT not found /usr/lib/elm/vendor/elm-make

If you can flesh out the particulars of the error, we can figure out if that is our-problem and try to fix it in the next release or not-our-problem and try to route you to a fix anyway. If it is our-problem we will add it to this table.

Alleviating Struggles

npm

I have removed the npm installer from the typical install path. It seemed that lots of beginners had a particularly confusing time with ELM_HOME being messed up since a lot of resources say use elm-reactor as the first thing. This is particularly tragic for folks on OSX or Windows who don't have to have problems if they use the official distribution.

Thanks to some changes in elm-reactor no one will need to use ELM_HOME at all in the next release. I also plan to build 32-bit binaries on a Debian variant so we resolve that corner case.

Improving "build from source"

Without npm working, all Linux folks are building from source. This is probably worse than the npm problems. Issue #63 is tracking progress on a potentially more reliable way to build 0.15.1 from source.

Avoid "build from source" more often

I'd be interested to get the breakdown of users within Linux. I have a suspicion that Ubuntu or variations of Debian account for the majority of folks there.

If that is true, my priority would be trying to get npm install -g elm working there without the ELM_HOME issue. I think this is nicer than apt-get install in certain ways.

After that, I am not sure how to take additional steps. I don't know anything about arch or nix or whatever. My goal would be for the Elm Platform to be distributed in the same way that python or gcc or any other typical package is distributed. I don't know what steps I need to take to make that happen.

[jvoigtlaender]

Possible addition to the list of alternatives concerning "building from source":

• Remove all bounds from the .cabal files for elm-platform binaries, download the latest version of https://www.stackage.org/lts/cabal.config (the latest one which is compatible with the GHC that you, Evan, currently use), check in that file. Before a release, download the then latest version of https://www.stackage.org/lts/cabal.config and check it in, overwriting the previous one.

If more details are desired in a gist, which ones?

[evancz]

@jvoigtlaender, I am trying out cabal.config in #63. I'm just using cabal freeze because it works for 0.15.1 whereas the stackage things do not.

[rtfeldman]

I believe all the npm issues mentioned here have now been resolved.