How should we instruct people to install Elm?

I’m trying to teach some people how to code.
I had them install Elm (on OS X) by following the instructions here:
They couldn’t run elm-repl because their /usr/local/bin was root-only.
Googling “fix usr local permissions os x” yielded many discussions and possible solutions.
Running sudo chown -R $(whoami) /usr/local/* seemed to do the trick.

(Note that in the interim we tried, the REPL suggested at It has a bug where you can get other people’s output. So we learned that 55 = 121.)

OK, finally we can run elm-repl. Now we’re told we need to install Node first.
Now, if I have my students install Node, will this work, or will there be something else?
Would we be better off installing via homebrew? Presumably that would take care of the elm -> node dependancy (and any others) as well as permissions apparently.

I’d recommend elm-format to any new user (as the install article does), so that might be another point for homebrew.

Any other suggestions as to how a person should install Elm?

What OS they are running? What permissions do they have? That may help give better recommendations.

I suspect in most cases, the most reliable path is to say “Install node from here and then run npm install -g elm to get Elm.” At that point the only possibility is the permissions thing.

Perhaps you could have them run mv /usr/local/bin/elm* somewhere and then put PATH=somewhere:$PATH in their ~/.bashrc to avoid messing with permissions.

Note: I guess we are supposed to put binaries somewhere else now. Where is “the right place” though? We could do it in 0.19 if there is an agreed upon location that doesn’t have this issue.

I am a fan of using $HOME/.local/bin. It is included in $PATH on many Linux distributions and never has a permissions issue. I also think simply that using $HOME/.elm might be a good spot for global Elm files in the future, if necessary. That makes it really easy to rm -r ~/.elm and re-download anything in the case of a cache corruption issue or something similar.

1 Like

I always recommend people to use the npm installer. I would consider it to be the canonical way to install Elm: it’s straightforward, and cross-platform.

However, one piece of advice I would give whenever someone runs into these issues: setup npm so that global installs are per-user, rather than put in the shared directories. Most machines only have one user, anyway, and it prevents NPM messing with permissions:


I think about the install instructions for F# - there are three installation options. A newcomer then wonders, which is the better? One “official” method of installation is preferable and removes choice anxiety. It is also easier to support and assist.

Also, for people that don’t even have Node on their machines yet, I suggest installing Node with NVM (Node Version Manager). It takes care of puting everything in user space, and add flexibility for your Node installation. Then just npm install -g elm (no sudo), no need to change any config or permission. It’s basically trading one config for one tool (NVM), which might be a good or a bad thing (another indirection) depending on context.

Seems like it would be more appropriate to have the script in the generic OS package manager (e.g. homebrew) do the right thing (whatever that is), rather than promoting workarounds. It’s not like homebrew is closed source!


At least on Arch Linux I’ve run into a permissions issue using npm. I had to use nvm, then have a system npm and a user npm version to avoid this problem.

I had a student install Elm via homebrew and have no problems with that.
elm-repl told her to install node, and she could install it the same way she just installed Elm: brew install node.
And when I suggest installing elm-format, she can do it the same way.

I like the idea of recommending install via approved package managers, given that they solve a number of problems a user may encounter. Ruby install instruction ( start with installing via package managers.

1 Like

It seems to me using the NPM Elm installer with Yarn instead of NPM would alleviate some of the permissions problems, because Yarn globally installs stuff to some subpath of ~ and not into /usr/local/ (as NPM does).

1 Like

I continue to be a big fan of Nix for this sort of thing. You can use it to build a custom environment that includes all the tools your students will need, including things like git or an IDE. This environment is guaranteed to be reproducible across machines, free of permissions problems, and immune to breakage due to OS updates.

For example, if you want to start hacking on my photo album project, you can just run nix-shell with the provided shell.nix and it will automagically download a working version of Elm, Haskell, and all the Haskell libraries you need, setting up your $PATH etc. to point to them.

The main downside is that it’s not really supported on Windows. :frowning:

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.