Куда в virtualenv идет собственный код?

Какой структуре каталогов следует придерживаться при использовании 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. Или вы можете тестировать приложение с помощью virtualenv, которое позже будет развернуто с системным Python. Или вы можете упаковывать автономное приложение, в котором может иметь смысл разместить каталог virtualenv где-то внутри самого каталога приложения.

Так что в целом я не думаю, что есть один правильный ответ на этот вопрос. И что хорошо, так 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

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

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

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

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

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

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