Assumes /usr/local/bin is first instance of Elm binaries in $PATH - not true for nvm etc.

[inactivist]

I've previously used nvm to manage node versions locally.

So, I've installed Elm and related tools in an nvm-managed Node installation, which places installed files in ~/.nvm/versions/node/$NODE_VERSION/lib/node_modules and creates symlinks in ~/.nvm/versions/node/$NODE_VERSION/bin.

nvm alters $PATH to use ~/.nvm/versions/node/$NODE_VERSION/bin first, so the evm-managed Elm versions are not used.

[inactivist]

IIRC nvm alters path depending on activated Node version (so it doesn't copy / unlink / link files at all on switch).

[ronnross]

Any ideas on how one would fix this @inactivist ?

[mattludwigs]

@inactivist do you know if nvm does:

PATH=~/.nvm/versions/node/$NODE_VERSION/bin:$PATH

I guess some solutions might be to try to change the PATH with evm, or to see if .nvm exists and do some extra work to account for that.

I am not sure how users feel about us just changing the PATH however if they are using nvm they probably don't mind. We could have them manually do it, but my goal was to try to automate that as much as possible so people who are less bash inclined would not have to worry about those extra steps.

Any thoughts @ronnross or @inactivist?

[inactivist]

@ronnross Not as yet. Not even sure it's something that should be fixed here... just raising the issue to get discussion rolling.

I will say my preference would be to do something like what nvm does, which doesn't alter global state, and doesn't copy/symlink except during installation of a particular node version - it just alters the local $PATH to point to the selected node version cached in $/.nvm/versions/node/$NODE_VERSION/bin. Not sure how much work it is to do that.

@mattludwigs:

@inactivist do you know if nvm does: PATH=~/.nvm/versions/node/$NODE_VERSION/bin:$PATH

Yeah, looks like ~/.nvm/nvm.sh does that in nvm_prepend_path - nvm.sh is sourced in .bashrc (for example)

While I agree some users may dislike evm changing the path, there's a clear example of it being done in nvm for similar purposes. In addition, nvm's approach is less intrusive; it alters $PATH in the current shell only, where evm alters the global elm instance in /usr/local/bin -- evm's current approach will probably lead to breakage for those who run multiple shell instances or otherwise run or develop multiple Elm apps concurrently (not that rare for me -- usually have several shell windows open on several Elm projects, some are 0.17.0, a few new ones are 0.18.0)

[mattludwigs]

@inactivist I am liking your idea. I did not think about that use case, and I would prefer not to affect the global system.

I use n and they append the n path to the back of the path so that is why I did not have any issues. However n writes to the .bash_profile to automatically set up a the default node version.

and now I remember when I did have nvm installed and was using that I had to the add the nvm use <some-version> in the .bash_profile so when I started a new session it would automatically use that version.

I guess a follow up question I have is:

Do you think we follow n's way of writing to the profile file to run evm use <some-version> or do we do the nvm way and just up the path. If a user wants a default they can set it manually in their profile.

Maybe phase one we set the path correctly, and give information on how to add the default to the profile. Then, phase two can be writing to the profile file, and giving adding a new cli command to set the default? Or maybe a project local .evmrc file like nvm does?

At this point my main goal will to be fix this so users with nvm install don't have the same issues as you do. Then, we can make it more fancy.

What are your thoughts?

My goal is to get this fixed and up to npm by the end of next week, hopefully sooner.

[inactivist]

@mattludwigs I don't use n so have no input there. I do know I like the way nvm works, seems fairly natural to me. (I'm not a Node power user so YMMV.)

In any case, no matter how you decide to proceed, I think it's a big win if evm can stop altering global /usr/local/bin, copying/symlinking on every use etc. Can't comment on n way but the nvm method (just update path to point to installed binaries and symlinks) seems pretty sane to my biased mind.

Another potential issue when using nvm or n: are there any problems lurking because evm points to an Elm install outside the current node environment? I'm thinking no, but...

In any case I admit I'm uncertain about the level of effort to make this work cleanly with different environments. Much gratitude for your attention and effort.

[mattludwigs]

The effort should not be too bad. I am thinking I am going to have to call a bash script to set the users path when the use the use command.

Thank you for your thoughts and input on this, I needed some extra input because I was not really found of the current solution either. I hope to get this fix in by the end of the week. We will see though this thanks giving this week how much I can get done. And feel free, if you have time or want to, to make a PR if you are able to get to it before me. Once I start I will assign this to myself so you can reference that as an indicator if I started or not.

[Natim]

I guess the way to do that would be do use which:

which elm, it could also explicitly ask people to add a specific directory in their PATH for this software to work.

[mattludwigs]

Sorry given the thanksgiving day week I was not able to get to this yet

[mattludwigs]

sorry I have been slow on this, last week at work was pretty busy, planning on taking a look this coming week

[inactivist]

No worries, @mattludwigs -- I appreciate whatever you can do on this, on your time schedule. If it was higher priority for me right now, I'd pitch in and submit a PR.