Skip to content
This repository has been archived by the owner on Dec 6, 2023. It is now read-only.

avn-nvm aliases #43

Open
1 task done
hiendv opened this issue Jul 1, 2016 · 19 comments
Open
1 task done

avn-nvm aliases #43

hiendv opened this issue Jul 1, 2016 · 19 comments

Comments

@hiendv
Copy link
Contributor

hiendv commented Jul 1, 2016

Details

  • avn 0.2.3
  • node v6.2.2
  • nvm 0.31.2
  • bash 4.3.42(1)

The output of __avn_debug in the directory with a .node-version file is:

avn could not activate node default
error: no plugin passed predicate
  avn-nvm: no version matching default

avn is loaded in my ~/.{bash|zsh}{_profile|rc} file with:

[[ -s "$HOME/.avn/bin/avn.sh" ]] && source "$HOME/.avn/bin/avn.sh" # load avn

nvm specific

  • As an nvm user I am confirming that I did not install with Homebrew
@hiendv
Copy link
Contributor Author

hiendv commented Jul 1, 2016

.nvmrc

default

@wbyoung
Copy link
Owner

wbyoung commented Jul 14, 2016

@hiendv yes, we should do one of two things:

  • Support it
  • Simply notice that it's an alias and ignore it

The idea behind nvm is to establish a per project-based version of node, so I'm actually leaning more toward the idea of ignoring it. But it'll still require some changes to ignore, and should certainly be done so that a ~/.nvmrc w/ an alias doesn't cause avn to freak out.

@hiendv
Copy link
Contributor Author

hiendv commented Jul 14, 2016

From my point of view, avn and nvm match perfectly. One makes project-based versioning possible, the other makes the whole process automatically. So why ignoring it, @wbyoung ?
Anyway, there's no need for avn to care about nvm aliases but avn-nvm should, imo.
Thank you for considering this.

@ljharb
Copy link

ljharb commented Jul 14, 2016

.nvmrc is not just per-project - ~/.nvmrc and /.nvmrc, etc, are all valid use cases.

@wbyoung
Copy link
Owner

wbyoung commented Jul 14, 2016

@ljharb right, which is why I don't want to do anything silly if we read those files (which we do during directory traversal). avn, though, was created with the intention of being per-proejct and expanded to handle .nvmrc files.

@ljharb
Copy link

ljharb commented Jul 14, 2016

what denotes a project root in avn?

@wbyoung
Copy link
Owner

wbyoung commented Jul 14, 2016

@ljharb previously a .node-version file, but after #17 was addressed, it's really either an .nvmrc or .node-version file. I understand that this isn't perfect and that it also doesn't really fit well the same things that the .nvmrc file is trying to accomplish.

This same line of thinking has been previously discussed.

And I think it's worth noting that #17 was implemented to avoid duplication between two different files.

I'm still thinking that ignoring aliases in .nvmrc files w/ aliases seems like an appropriate course of action. It basically says, you can use .nvmrc as a replacement to .node-version, but only if you're using it as a .node-version style file that doesn't support aliases.

@ljharb
Copy link

ljharb commented Jul 14, 2016

I don't think that's good at all. If you're going to support .nvmrc, support it - otherwise, please don't. I don't want a slew of bug reports because .nvmrc only half-works in avn.

@ljharb
Copy link

ljharb commented Jul 14, 2016

Also please note that LTS support is coming to .nvmrc shortly, and there's very little purpose in putting a full version number in that file. The common use cases are going to be node, lts/*, lts/argon, etc.

@wbyoung
Copy link
Owner

wbyoung commented Jul 14, 2016

@ljharb okay, we'll try to support it.

Also, if there's little point in putting a version number in that file, the docs should probably be updated when you do support that so your example is more in line with how things should be used in the majority use case.

A quick question about how to get things accomplished on this side:

  • Is there a way to resolve node or lts/argon into a version number when it's read from the .nvmrc file? Any command that can be run?

@ljharb
Copy link

ljharb commented Jul 14, 2016

@wbyoung nvm version "${NVM_RC_CONTENTS}" should do it

@wbyoung
Copy link
Owner

wbyoung commented Jul 14, 2016

@ljharb thanks.

To support this, we'll need to update avn-nvm which receives the version in the match function and either use the command listed above to convert to a real version before searching installed versions or just treat it specially if it doesn't look like an installed version, skipping the search entirely.

Note that we still want to allow search of installed versions when it's a version number because if it comes from a .node-version file, we want the best option between installed avn plugins.

PR welcome!

@ljharb
Copy link

ljharb commented Jul 14, 2016

nvm version already searches nvm-installed versions for you, fwiw.

@duckontheweb
Copy link
Contributor

@ljharb @wbyoung If no one is currently working on a PR for this I'm happy to put one together.

@wbyoung
Copy link
Owner

wbyoung commented Nov 12, 2017

@duckontheweb please do!

@duckontheweb
Copy link
Contributor

duckontheweb commented Nov 14, 2017

I have tests and working support for aliases written on a fork of avn-nvm. Support for the system alias in an .nvmrc file is going to take a bit more work since nvm version system resolves to system. I think I could use nvm unload and then which node and node --version to grab the system version if the version resolves to system after the other checks.

@ljharb
Copy link

ljharb commented Nov 15, 2017

@duckontheweb nvm run system --version?

@duckontheweb
Copy link
Contributor

@ljharb I ended up going with nvm use system > /dev/null && node --version because nvm run system --version gave a line of output before echoing the version number and it made things easier to parse. Would there be any advantage to using nvm run system --version over this approach?

@ljharb
Copy link

ljharb commented Nov 16, 2017

@duckontheweb you can use nvm run --silent system --version, or nvm exec --silent system node --version; the advantage is that it's a single command.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants