Virtualenv Uses Wrong Python, Even Though It Is First in $Path

Virtualenv uses wrong python, even though it is first in $PATH

If you don't get the program that which says you should get, you need to look higher up the chain than the platform executor. Shells typically have a way to alias commands and on most unixy shells you can just enter alias to see which commands have been remapped. Then its just a matter of going to the config files for your shell and removing the alias.

Sometimes people alias python to try to sort out which python they should be using. But there are usually other, better ways. On my linux machine, for example, python3 is in the path but is a symlink to the real python I am using.

td@mintyfresh ~ $ which python3
/usr/bin/python3
td@mintyfresh ~ $ ls -l /usr/bin/python3
lrwxrwxrwx 1 root root 9 Feb 17  2016 /usr/bin/python3 -> python3.4
td@mintyfresh ~ $ 

This is nice because non-shell programs running python get the same one I do and virtual environments work naturally.

python still runs the system version after virtualenv activate

Bottom line:

You have set "python" as a shell alias (probably in your shell startup scripts). It interferes with virtualenv's work of replacing what would be run when you type "python". Remove the alias, and you're good.

You also don't need to specify --python=/usr/local/bin/python2.7 'cuz you're using virtualenv from that Python installation, so it already uses it by default.

---

WFM with virtualenv 1.10.1: (see a guess further below)

$ virtualenv --python=/usr/local/bin/python2.7 testbox
Running virtualenv with interpreter /usr/local/bin/python2.7
New python executable in testbox/bin/python2.7
Also creating executable in testbox/bin/python
Installing Setuptools.........................................done.
Installing Pip................................................done.
$ ls -l testbox/bin/
total 40
-rw-r--r--. 1 root root 2194 Dec  7 03:06 activate
-rw-r--r--. 1 root root 1250 Dec  7 03:06 activate.csh
-rw-r--r--. 1 root root 2389 Dec  7 03:06 activate.fish
-rw-r--r--. 1 root root 1129 Dec  7 03:06 activate_this.py
-rwxr-xr-x. 1 root root  332 Dec  7 03:06 easy_install
-rwxr-xr-x. 1 root root  340 Dec  7 03:06 easy_install-2.7
-rwxr-xr-x. 1 root root  293 Dec  7 03:06 pip
-rwxr-xr-x. 1 root root  301 Dec  7 03:06 pip-2.7
lrwxrwxrwx. 1 root root    9 Dec  7 03:06 python -> python2.7
lrwxrwxrwx. 1 root root    9 Dec  7 03:06 python2 -> python2.7
-rwxr-xr-x. 1 root root 7788 Dec  7 03:06 python2.7

And the main thing that activate does is:

PATH="$VIRTUAL_ENV/bin:$PATH"
export PATH

---

My guess is that you're using virtualenv that was installed for your /usr/local/bin/python2.7. That's the reason for the "Already using..." message. If that's the case, you don't need to pass --python because that virtualenv is already using it by default (check its shebang).

Still, since virtualenv creates a versionless executable and activate alters PATH, you should get /var/python_venv/testbox/bin/python as python.

• Since python is an alias in your case, and activate doesn't use aliases - you must have it set in your bash startup scripts.

Pip is selecting wrong path

to fix do this :

1. check if you still have the python38-32 folder in your local variable list

2. Delete the "%userprofile%\AppData\Local\Programs\Python\Python38" folder

3. run pip from command line

if the problem still persists then type "environment variables" in the windows search box

and add "%userprofile%\AppData\Local\Programs\Python\Python37" to your system variable named "Path"

This should completely fix your problem

if not

1. uninstall all the python files including py launcher
2. reinstall python # when installing you must select ADD PYTHON to system environment variable

virtualenv' is not recognized as an internal or external command, operable program or batch file

steps:
- go to where you want create django app on that folder.

then run this command on command prompt : python -m virtualenv .

(eg. C:\Users\gshiv\Desktop\django>python -m virtualenv .)

where django is the my folder i want run virtualenv and .(dot) indicates virtualenv install all it's folder in django folder otherwise you can use other folder name instead .(dot) this time virtulenv creates a folder in main folder(django) .

• after running this command: run .\scripts\activate now you can see this type of line on cmd-prompt (django) C:\Users\gshiv\Desktop\django>
• i.e main folder name before the source path. now you can install any modules for your project that belongs to that main folder only.

pip install django works fine.

Can't Find or create a new virtualenv

Using virtualenv

First of all you should verify that virtualenv is really installed for Python 3.5:

python3.5 -m pip list

If it's not then install it either with the package manager of your distribution or by running python3.5 -m pip install virtualenv.

Then you can run python3.5 -m virtualenv <newvenv> and it should create a new virtualenv using Python 3.5 for you.

Using venv that is already part of the standard library in Python 3.5

Simply running python3.5 -m venv <newvenv> should do the job.

How to make Python version executables global across multiple pyenv-virtualenv virtual environments

You can directly execute the pipx binary in the pyenv prefix, it should work correctly.

Pyenv's shims mechanism isn't really designed for global binaries like this. I naively expected that the global environment would act as fallback when a local environment doesn't have an installed binary, but I think pyenv only looks at the system Python before falling back to $PATH.

So, if you don't install pipx into system (which, if you're not installing a system pip, I doubt you're doing), then the naive fallback doesn't work.
An alternative is to run pyenv with a temporary environment, i.e.
PYENV_VERSION=my-pipx-env pyenv exec pipx.

I'd want to make this an executable, so I'd suggest adding something like this into a special PATH directory that takes precedence from the pyenv paths:

#!/usr/bin/env bash
set -eu

export PYENV_VERSION="pipx"
exec "${PYENV_ROOT}/libexec/pyenv" exec pipx "$@"

Although, I'd be tempted to forgo the whole activation logic and just directly exec the pipx binary from the environment /bin to avoid running into any shell configuration errors.

---

Related Topics