Где в виртуальном окружении находится пользовательский код?
-
21-09-2019 - |
Вопрос
Какой структуры каталогов следует придерживаться при использовании virtualenv
?Например, если бы я создавал приложение WSGI и создал виртуальную среду под названием foobar
Я бы начал со структуры каталогов, например:
/foobar
/bin
{activate, activate.py, easy_install, python}
/include
{python2.6/...}
/lib
{python2.6/...}
Как только эта среда будет создана, где можно будет разместить свои собственные:
- файлы Python?
- статические файлы (изображения/и т. д.)?
- «индивидуальные» пакеты, например, те, которые доступны в Интернете, но которых нет в сырной лавке?
по отношению к virtualenv
каталоги?
(Предположим, я уже знаю куда должны идти сами каталоги virtualenv.)
Решение
virtualenv
предоставляет экземпляр интерпретатора Python, а не экземпляр приложения.Обычно вы не создаете файлы приложения в каталогах, содержащих системный Python по умолчанию, также нет необходимости размещать ваше приложение в каталоге virtualenv.
Например, у вас может быть проект, в котором несколько приложений используют одну и ту же виртуальную среду.Или вы можете тестировать приложение с помощью virtualenv, которое позже будет развернуто с помощью системного Python.Или вы можете упаковывать отдельное приложение, и имеет смысл разместить каталог virtualenv где-то внутри самого каталога приложения.
В общем, я не думаю, что есть один правильный ответ на этот вопрос.И что хорошего в virtualenv
заключается в том, что он поддерживает множество различных вариантов использования:не обязательно должен быть один правильный путь.
Другие советы
Если у вас время от времени всего несколько проектов, ничто не мешает вам создать новую виртуальную среду для каждого из них и поместить туда свои пакеты:
/foobar
/bin
{activate, activate.py, easy_install, python}
/include
{python2.6/...}
/lib
{python2.6/...}
/mypackage1
__init__.py
/mypackage2
__init__.py
Преимущество этого подхода в том, что вы всегда можете быть уверены, что найдете внутри скрипт активации, принадлежащий проекту.
$ cd /foobar
$ source bin/activate
$ python
>>> import mypackage1
>>>
Если вы решите быть более организованным, вам следует подумать о том, чтобы поместить все ваши виртуальные среды в одну папку и назвать каждую из них в честь проекта, над которым вы работаете.
/virtualenvs
/foobar
/bin
{activate, activate.py, easy_install, python}
/include
{python2.6/...}
/lib
{python2.6/...}
/foobar
/mypackage1
__init__.py
/mypackage2
__init__.py
Таким образом, вы всегда можете начать заново с новой виртуальной средой, если что-то пойдет не так, и файлы вашего проекта останутся в безопасности.
Еще одним преимуществом является то, что несколько ваших проектов могут использовать одну и ту же виртуальную среду, поэтому вам не придется выполнять одну и ту же установку снова и снова, если у вас много зависимостей.
$ cd /foobar
$ source ../virtualenvs/foobar/bin/activate
$ python
>>> import mypackage2
>>>
Для пользователей, которым регулярно приходится настраивать и удалять виртуальные среды, имеет смысл взглянуть на virtualenvwrapper.
http://pypi.python.org/pypi/virtualenvwrapper
С помощью virtualenvwrapper вы можете
* create and delete virtual environments
* organize virtual environments in a central place
* easily switch between environments
Вам больше не придется беспокоиться о том, где находятся ваши виртуальные среды при работе над проектами «foo» и «bar»:
/foo
/mypackage1
__init__.py
/bar
/mypackage2
__init__.py
Вот как вы начинаете работать над проектом «foo»:
$ cd foo
$ workon
bar
foo
$ workon foo
(foo)$ python
>>> import mypackage1
>>>
Тогда переключение на проект «бар» происходит так же просто:
$ cd ../bar
$ workon bar
(bar)$ python
>>> import mypackage2
>>>
Довольно аккуратно, не так ли?
Поскольку virtualenv нельзя перемещать, на мой взгляд, размещать файлы проекта в каталоге virtualenv — плохая практика.Virtualenv сам по себе является сгенерированным артефактом разработки/развертывания (что-то вроде файла .pyc), а не частью проекта;его должно быть легко удалить и воссоздать в любое время или создать новый на новом хосте развертывания и т. д.
Многие люди на самом деле используют виртуальная оболочка, который почти полностью удаляет из вашего внимания фактические виртуальные среды, помещая их все рядом в $HOME/.virtualenvs по умолчанию.
Если вы дадите своему проекту setup.py
, pip может импортировать его напрямую из системы контроля версий.
Сделайте что-то вроде этого:
$ virtualenv --no-site-packages myproject
$ . myproject/bin/activate
$ easy_install pip
$ pip install -e hg+http://bitbucket.org/owner/myproject#egg=proj
Тем -e
внесу проект в myproject/src
, но свяжите его с myproject/lib/pythonX.X/site-packages/
, поэтому любые внесенные вами изменения будут немедленно отражены в модулях, которые импортируют их из вашего локального site-packages
.Тем #egg
bit сообщает pip, какое имя вы хотите дать пакету яйца, который он создаст для вас.
Если вы не используете --no-site-packages
, будьте осторожны и укажите, что вы хотите, чтобы pip был установлен в virtualenv с помощью -E
вариант