Использование VirtualEnv с несколькими версиями Python на окнах

У меня есть python 2.7.6 и 3.4.0 на моей машине. Версия 2.7 на моем пути. Я хотел бы настроить virtualenv, используя 3.4. Есть много сообщений о SO и в других местах, которые предлагают мне сделать следующее из командной строки:

virtualenv -p c:\python34 myvirtualenv

но это не работает для меня. Сеанс консоли имеет права администратора и UAC выключен, однако я получаю проблему с разрешениями:

F:\virtualenv>virtualenv -p c:\python34 myenv
Running virtualenv with interpreter c:\python34
Traceback (most recent call last):
  File "c:\python27\scripts\virtualenv-script.py", line 9, in <module>
    load_entry_point('virtualenv==1.11', 'console_scripts', 'virtualenv')()
  File "C:\Python27\lib\site-packages\virtualenv.py", line 779, in main
    popen = subprocess.Popen([interpreter, file] + sys.argv[1:], env=env)
  File "C:\Python27\lib\subprocess.py", line 709, in __init__
    errread, errwrite)
  File "C:\Python27\lib\subprocess.py", line 957, in _execute_child
    startupinfo)
WindowsError: [Error 5] Access is denied

Я также пробовал это, конкретно указывая на версию virtualenv версии 3.4, но без изменения пути он заканчивает выполнение смешанного пакета файлов с файлами 2.7 и 3.4.

Единственный способ, которым я мог бы найти настройку своей виртуальной среды, - это изменить мой путь до 3.4, запустить virtualenv, затем reset мой путь до 2.7, который побеждает точку переключателя python на virtualenv.

Спасибо

Ответы

Ответ 1

лучше:

py -3.4 -m venv c:\path\to\wherever\you\want\it

Если у вас нет пусковой установки py.exe (но она должна быть установлена), вы можете заменить py -3.4 на c:\Python34\python.exe (предполагая местоположение по умолчанию)

Это работает из-за удобного, удобного в использовании Windows, супер-красивого выбора времени выполнения py.exe

По умолчанию py.exe будет присутствовать при установке Windows (я думаю, что он поставляется с 2,7, я знаю, что он работает с 3+). Когда вы запустите py, тогда он будет искать некоторые переменные среды или вы можете переопределить это с определенным номером проверки (в вашем случае -2.7 или -3.4). Вы можете оставить .4 и выбрать "самый большой" номер версии.

Вы также можете использовать его для запуска скриптов Python. Если вы помещаете строку хеширования вверху вашего script #!python3 и называете ее py myscript.py, тогда она выберет правильную версию Python для начала, выполнив поиск в первой строке script и поиске для номера версии.

Это классно, потому что вы можете поместить что-то вроде #!/usr/bin/env python3.4 в начало вашего script и запустить его в Windows с помощью py или на linux, выполнив

$ chmod +x myscript.py
$ ./myscript.py

Довольно полезно.

Ответ 2

В Windows вам нужно запустить:

virtualenv -p c:\python34.exe myvirtualenv

.exe на конце делает всю разницу.

Ответ 3

Придется поиграть с этим какое-то время, чтобы понять это правильно. Если бы Python2.7.9 был установлен (Windows 7), он хотел взять последнюю версию Python3 для вращения. После установки Python3.4.3 я пошел в панель каталогов и создал виртуальную среду foo с помощью этой команды:

virtualenv -p c:\Python34\python.exe foo

Мне потребовалось некоторое время, чтобы понять, что мне нужно установить интерпретатор Python3.4.3 в "нормальном" режиме, изначально я думал, что он будет установлен USING virtualenv. Это было объяснено в этом ответе. Я не касался pythonpath в Windows после установки Python3.4.3.

Ответ 4

Если вышеуказанные меры не работают, попробуйте это (используя venv вместо virtualenv):

python -m venv venvname

(замените python на путь python.exe, если он не указан в настройках пути переменной окружения)

Ответ 5

Используя GitBash в Windows, у меня возникли некоторые проблемы с тем, чтобы заставить это работать.

У меня был Python 3.6 по пути Windows, но я пытался создать виртуальную среду Python 2.7 для тестирования старого проекта.

В конце концов получил его через:

1. adding the C:\Python27 path to my Windows environment variables 
2. virtualenv -p c:/python27/python.exe venvname

(а до этого мне приходилось ломать голову над добавлением модуля virtualenv)