Где в виртуальном магазине идет пользовательский код?

Question

Какую структуру каталогов следует использовать при использовании virtualenv? Например, если бы я строил приложение WSGI и создал virtualenv под названием foobar я начал бы со структурой каталогов, как:

/foobar 
    /bin 
    {activate, activate.py, easy_install, python} 
    /include 
    {python2.6/...} 
    /lib 
    {python2.6/...} 

После этого среда создается, где бы в одном месте свои собственные:

• файлы python?
• статические файлы (изображения/etc)?
• «пользовательские» пакеты, например, доступные в Интернете, но не найденные в магазине сыра?

относительно каталогов virtualenv?

(Предположим, что я уже знаю where the virtualenv directories themselves should go.)

Answer 1

virtualenv предоставляет экземпляр питон переводчика, а не экземпляр приложения. Обычно вы не создавали файлы приложений в каталогах, содержащих системный Python по умолчанию, также нет необходимости находить ваше приложение в каталоге virtualenv.

Например, у вас может быть проект, в котором у вас есть несколько приложений, использующих тот же самый virtualenv. Или вы можете тестировать приложение с помощью virtualenv, которое позже будет развернуто с помощью системы Python. Или вы можете упаковывать автономное приложение, где имеет смысл иметь каталог virtualenv, расположенный где-то в самой папке приложения.

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

Answer 2

Если у вас есть только несколько проектов, каждый так часто, ничто не мешает вам создать новый 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 в одну папку, и имя каждого из них после того, как проект, который вы работаете.

/virtualenvs 
    /foobar 
     /bin 
     {activate, activate.py, easy_install, python} 
     /include 
     {python2.6/...} 
     /lib 
     {python2.6/...} 
    /foobar 
    /mypackage1 
     __init__.py 
    /mypackage2 
     __init__.py 

Таким образом, вы всегда можете начать с нового virtualenv, когда все пойдет не так, и ваши файлы проектов остаются в безопасности.

Еще одно преимущество заключается в том, что некоторые из ваших проектов могут использовать один и тот же virtualenv, поэтому вам не придется делать одну и ту же установку снова и снова, если у вас много зависимостей.

$ cd /foobar 
$ source ../virtualenvs/foobar/bin/activate 
$ python 
>>> import mypackage2 
>>> 

Для пользователей, которые регулярно приходится устанавливать и разрывать virtualenvs было бы целесообразно, чтобы посмотреть на virtualenvwrapper.

http://pypi.python.org/pypi/virtualenvwrapper 

С virtualenvwrapper вы можете

* create and delete virtual environments 

* organize virtual environments in a central place 

* easily switch between environments 

Вам больше не придется беспокоиться о том, где ваши virtualenvs находятся при работе над проектами "Foo" и "бар":

/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 
>>> 

Очень аккуратно, не так ли?

Answer 3

Если вы дадите свой проект setup.py, пип может напрямую импортировать его из контроля версий.

ли что-то вроде этого:

$ 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 указано, какое имя вы хотите отдать пакету яйца, который он создает для вас.

Если вы не используете --no-site-packages, будьте осторожны, чтобы указать, что вы хотите пип установить в virtualenv с -E опцией

Answer 4

Поскольку virtualenvs не перемещаются, на мой взгляд, это плохая практика размещения ваших файлов проекта в каталоге virtualenv. Сам virtualenv является сгенерированным артефактом разработки/развертывания (вроде файла .pyc), а не частью проекта; это должно быть легко удалять и воссоздавать его в любое время или создавать новый на новом развертывающем узле и т. д.

Многие люди фактически используют virtualenvwrapper, который практически полностью удаляет виртуальные виртуальные объекты из вашей осведомленности, помещая их все бок о бок в $ HOME/.virtualenvs по умолчанию.