nenv supports partial versions, aliases

[madumlao]

The default nenv uses exact version matching to find a prefix as intended. However, you can use symlinks to create as many aliases for the current nenv as wanted, including the use of prefixes. This is not technically a hack as the rbenv family of environment groomers all work by using the directory name to set the version, and in many of these have a plugin similar to rbenv-aliases / phpenv-aliases even automatically creates symlinks to partial versions for you. In some of these, such as jenv, however, directly manipulating the prefix directories with symlinks is a recommended / common workflow.

So please indicate that partial versions is supported for nenv through the use of prefix symlinks.

I am the maintainer of phpenv [1], and a contributor to nenv [2] and jenv [3]. I am also the maintainer of phpenv-aliases [4]. If needed, I will clone an nenv-aliases repository right now.

[1] https://github.com/phpenv/phpenv
[2] https://github.com/ryuone/nenv
[3] https://github.com/jenv/jenv
[4] https://github.com/madumlao/phpenv-aliases

[madumlao]

Likewise please also indicate that nenv supports leading v through prefix symlinks.

[shadowspawn]

The ability to manually create symlinks is not what I have in mind as support for either partial versions or leading v in this context. If we share a project with a .node-version file and I use either of those patterns in the file, they are not going to work for you without you taking extra steps.

nodenv does support automatic creation of the partial version alias if you have the right pieces so I came up with 🧩 for some extra pieces required: #1 (comment)

It looks like phpenv-aliases and php-build play together the same way: https://github.com/madumlao/phpenv-aliases#php-build

If you're using php-build, phpenv install A.B.C automatically invokes phpenv alias A.B --auto, so you'll always have up to date aliases for point releases.

jenv creates multiple aliases when it inspects the installed version: https://github.com/jenv/jenv#12-adding-your-java-environment

$ brew install --cask java
$ jenv add "$(/usr/libexec/java_home)"
$ jenv versions
* system (set by /Users/user/.jenv/version)
  11.0
  11.0.2
  openjdk64-11.0.2

I'll add a link to this issue in the table, but further comments still welcome.

[madumlao]

The ability to manually create symlinks is not what I have in mind as support for either partial versions or leading v in this context. If we share a project with a .node-version file and I use either of those patterns in the file, they are not going to work for you without you taking extra steps.

I get what you mean, but for the env family of environment managers, it is incorrect to treat "creating symlinks" as unusual extra steps. It is entirely how they work and are meant to be used. For most of them even, the build component that implements the "install" function is not even included - it is assumed that you will take extra steps to actually manage php/ruby/java/etc build versions because the semantics of reading version numbers is not part of the package - it just so happens that most users will also use the -build plugin. Albeit, for nenv, the install component is included, but the core usage of nenv does not differ than phpenv, rbenv, etc and nothing even stops you from using your own build plugin for it.

I just think the correct rating, as a user/contributor to multiple _env systems and having dealt with the aliases problem before, is "supports with caveat", and not "unsupported with workaround".

[madumlao]

I think an analogy would be "does nginx support PHP"? With apache, the PHP support is built-in, with nginx, you use a different manual approach. But it would not be appropriate to have a support checklist and have an X in the "nginx supports PHP" box.

[shadowspawn]

Good explanation, thanks. I still think of this as "capable of" rather than "supports", but I accept the big ❌ looks wrong to an experienced env user! Upgraded to puzzle piece, so now same treatment for both env products.