Open inactivist opened 7 years ago
IIRC nvm alters path depending on activated Node version (so it doesn't copy / unlink / link files at all on switch).
Any ideas on how one would fix this @inactivist ?
@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?
@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)
@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.
@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.
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.
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.
Sorry given the thanksgiving day week I was not able to get to this yet
sorry I have been slow on this, last week at work was pretty busy, planning on taking a look this coming week
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.
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.