Also notable, IMO, is the lack of a tool like rbenv or rustup for python. I can't tell you how many times I have had to try to figure out which python version a given pip executable worked with.
Also notable, IMO, is the lack of a tool like rbenv or rustup for python. I can't tell you how many times I have had to try to figure out which python version a given pip executable worked with.
Node would be the last place I'd look for a good solution in. Not sure if there was some progress recently, but it was hell some time back. Modules were huge, taking thousands of other modules with them, majority of those being duplicates. There was no deduplication, no version wildcards I believe either. It wouldn't even work with some tools because the path would end up being hundreds of characters long.
There have always been version wildcards as far as I know. Long paths caused by the deeply nested tree were a problem in Windows only, addressed (I believe, I can't find open issues on it) by the flattening in npm 3.
Does pyenv not meet your needs there?
It also has plugins to automatically work with venv, if you don't mind some 'magic' in your workflow.
Overall it's a solid setup.
I've tried relocating node_modules. It's a recipe for pain and tears.
I don't see why it's a big problem that virtualenv is a package rather than built in.
I also haven't had much of a problem with virtualenv not being relocatable. If you want it somewhere else, just build it there.
>Also notable, IMO, is the lack of a tool like rbenv
Ummmmm the creator of rbenv also created pyenv.
pip does cache the wheels so instead of moving the virtualenvs around, just recreate them. This also ensures the virtualenv is up to date. Using tox this is fairly easy to do.
Sure virtualenv is a bit of a hack but it's not that bad.
venv is in the stdlib since 3.3. (Though I agree with the annoyance at the need.)