asdf 0.2.1
Python plugin installed with 2.7.10 and 3.6.0 versions
$ asdf global 2.7.10
$ mkdir version3
$ cd version3
$ asdf local python 3.6.0
$ pip -V
Outputs the correct version
pip 9.0.1 from /Users/<username>/.asdf/installs/python/3.6.0/lib/python3.6/site-packages (python 3.6)
$ virtualenv new
$ . new/bin/activate
$ pip -V
Outputs the WRONG version
pip 9.0.1 from /Users/<username>/version3/new/lib/python2.7/site-packages (python 2.7)
I don't know if I'm doing something wrong, but I expected pip to get the version of the current local config.
If its by virtualenv's design, please add a command asdf which python to get the path of the current python so we can pass to virtualenv's -p flag.
@fcrespo82 asdf current python may give you the information you need to pass to -p. I'm not too familiar with Python, but that behavior may be intended. @tuvistavie is this the way pip and asdf-python are suppose to work?
-p option requires the path, so asdf current will not do for this case.
I explicitly pass the path to python when I create a new virtualenv:
virtualenv -p ~/.asdf/installs/python/3.5.2/bin/python myenv
it could also be done with
virtualenv -p $(asdf where python 3.5.2)/bin/python myenv
but this also requires to explicitly pass the version,
so I agree being able to change this into
virtualenv -p $(asdf which python) myenv
would be an improvement.
What do you guys think?
For workaround I am doing
virtualenv -p $(asdf where python $(asdf current python))/bin/python myenv
@tuvistavie I think the addition of a which command would be a good idea.聽That would give us three related commands:
current - print the current version and the path to the tool-version filewhere - show the path to the root of a specific versionwhich - show the path to the current version of the specified executableRelated to #72
Closing since I don't think there is anything else asdf can do to make this easier. If anyone thinks of anything else that could be done to make this easier please create another issue here or on asdf-python (https://github.com/tuvistavie/asdf-python).
hmm, rbenv handles it pretty well, if asdf is going to be a replacement, it should handle something like this:
rbenv install 2.5.1
rbenv rehash
gem install rails
I think the equivalent for asdf would be:
asdf install ruby 2.5.1
asdf reshim ruby 2.5.1
asdf local ruby 2.5.1
gem install rails
Thanks @fcrespo82 for the workaround.
Another even shorter option we eventually found (just adding here for future references) is:
$(asdf where python)/bin/virtualenv myvenv
It will use the correct python version just as well.
If using Python3, I usually do
python -m venv myvenv
I never had any issue with this.
@danhper That's actually an even better solution, thanks! (I guess you meant python -m virtualenv myvenv right?)
I tested it and it's working also for python2. Have you seen specific case in python2 that it doesn't work?
For python -m virtualenv myenv to work, you need to have the virtualenv pip package installed. AFAIK, this is indeed the only way to get it to work for Python 2.
For Python >= 3.3, the module venv is part of the standard library so python -m venv myenv will work out of the box. But -m virtualenv would of course also work provided that the virtualenv package is installed.
@danhper I don't follow. That command would not create the virtualenv right? that looks like a way to prefix you python invocations (after you have activated the virtualenv).
python -m venv venv would indeed create a virtual environment in the venv directory relative to the current directory.
Unless using whatever shell hook, you would need to activate it using source venv/bin/activate or so though.
interesting, never heard of that and it works! Maybe you can edit your original comment to say makes a virtualenv using whatever is the current python.
Most helpful comment
If using Python3, I usually do
I never had any issue with this.