Python virtualenv вопросы

Question

Я использую VirtualEnv в Windows XP. Мне интересно, правильно ли мне обернули мой мозг:

Я запустил virtualenv ENV, и он создал C:\WINDOWS\system32\ENV. Затем я изменил свою переменную PATH, чтобы включить C:\WINDOWS\system32\ENV\Scripts вместо C:\Python27\Scripts. Затем я извлек Django в C:\WINDOWS\system32\ENV\Lib\site-packages\django-trunk, обновил переменную PYTHON_PATH, чтобы она указала на новый каталог Django, и продолжил easy_install другие вещи (которые, конечно, идут в мой новый каталог C:\WINDOWS\system32\ENV\Lib\site-packages).

Я понимаю, почему я должен использовать VirtualEnv, чтобы я мог запускать несколько версий Django и других библиотек на одном компьютере, но означает ли это, что для переключения между средами мне нужно в основном изменить мои переменные PATH и PYTHON_PATH ? Итак, я иду от разработки одного проекта Django, который использует Django 1.2 в среде с именем ENV, а затем изменю свой PATH и так, чтобы я мог использовать среду с именем ENV2, которая имеет версию dev для Django?

Это в основном так, или есть какой-то лучший способ автоматически сделать все это (я мог бы обновить свой путь в коде Python, но для этого потребовалось бы написать машинный код в моем приложении)?

Кроме того, как этот процесс сравнивается с использованием VirtualEnv в Linux (я довольно новичок в Linux).

Answer 1

Обычно virtualenv создает среды в текущем каталоге. Если вы по каким-то причинам не собираетесь создавать виртуальные среды в C:\Windows\system32, я бы использовал другой каталог для сред.

Вам не нужно связываться с путями: используйте скрипт activate (в <env>\Scripts), чтобы убедиться, что исполняемый файл Python и путь зависят от среды. После этого командная строка изменится, чтобы указать среду. Затем вы можете просто вызвать easy_install, и все, что вы установите таким образом, будет установлено в этой среде. Используйте deactivate, чтобы установить все обратно, как было до активации.

Пример:

c:\Temp>virtualenv myenv
New python executable in myenv\Scripts\python.exe
Installing setuptools..................done.
c:\Temp>myenv\Scripts\activate
(myenv) C:\Temp>deactivate
C:\Temp>

Обратите внимание, что мне не нужно было указывать путь для deactivate - activate делает это за вас, чтобы при активации «Python» запускал Python в virtualenv, а не в системном Python. (Попробуйте - сделайте import sys; sys.prefix, и он должен напечатать корень вашей среды.)

Вы можете просто активировать новую среду для переключения между средами / проектами, но вам нужно будет указать полный путь для activate, чтобы он знал, какую среду активировать. Вам никогда не нужно явно связываться с PATH или PYTHONPATH.

Если вы используете Windows Powershell, вы можете воспользоваться оболочкой . В Linux virtualenvwrapper (ссылка указывает на этот порт в Powershell) делает жизнь с virtualenv еще проще.

Обновление: Не совсем верно, но, возможно, не совсем в духе virtualenv. Вы могли бы пойти другим путем: например, если вы устанавливаете Django и все, что вам нужно для вашего сайта в вашем virtualenv, то вы можете работать в каталоге вашего проекта (где вы разрабатываете свой сайт) с активированным virtualenv. Поскольку он был активирован, ваш Python найдет Django и все, что вы легко установили в виртуальную среду: и поскольку вы работаете в каталоге вашего проекта, ваши файлы проекта будут видны и для Python.

Дальнейшее обновление: Вы должны иметь возможность использовать pip, distribute вместо setuptools и просто python setup.py install с virtualenv. Просто убедитесь, что вы активировали среду перед установкой чего-либо в нее.

Answer 2

Да, в основном это то, что делает virtualenv, и для этого нужна команда activate из документа здесь :

активация сценария

В только что созданном virtualenv будет скрипт оболочки bin / activ или командный файл Scripts / activ.bat в Windows.

Это изменит ваш $ PATH так, чтобы он указывал на каталог bin / virtualenv.В отличие от workingenv, это все, что он делает;это удобство.Но если вы используете полный путь, такой как / path / to / env / bin / python script.py, вам не нужно сначала активировать среду.Вы должны использовать источник, потому что он меняет среду на месте.После активации среды вы можете использовать функцию деактивации, чтобы отменить изменения.

Сценарий активации также изменит ваш запрос оболочки, чтобы указать, какая среда активна в настоящее время.

, поэтому вам следуетпросто используйте команду activate, которая сделает все это за вас:

> \path\to\env\bin\activate.bat

Answer 3

в Windows У меня установлен python 3.7, и я все еще не могу активировать virtualenv из Gitbash с помощью ./Scripts/activate, хотя он работал из Powershell после запуска Set-ExecutionPolicy Unrestricted в Powershell и изменения параметра «Да для всех».

Мне не нравится Powershell, и мне нравится использовать Gitbash, поэтому для активации virtualenv в Gitbash сначала перейдите в папку вашего проекта, используйте ls, чтобы просмотреть содержимое папки и убедиться, что вы видите "Сценарии».Измените каталог на «Сценарии», используя cd Scripts, как только вы попадете в путь «Сценарии», используйте . activate, чтобы активировать virtualenv.Не забудьте пробел после точки.

Answer 4

в моем проекте wsgi.py файл у меня есть этот код (он работает с virtualenv, django, apache2 в windows и python 3.4)

import os
import sys
DJANGO_PATH = os.path.join(os.path.abspath(os.path.dirname(__file__)),'..')
sys.path.append(DJANGO_PATH)
sys.path.append('c:/myproject/env/Scripts')
sys.path.append('c:/myproject/env/Lib/site-packages')
activate_this = 'c:/myproject/env/scripts/activate_this.py'
exec(open(activate_this).read())
from django.core.wsgi import get_wsgi_application
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")
application = get_wsgi_application()

в файле virtualhost conf у меня есть

<VirtualHost *:80>
    ServerName mysite
    WSGIScriptAlias / c:/myproject/myproject/myproject/wsgi.py
    DocumentRoot c:/myproject/myproject/
    <Directory  "c:/myproject/myproject/myproject/">
       Options +Indexes +FollowSymLinks +MultiViews
       AllowOverride All
      Require local
   </Directory>
</VirtualHost>