Куда в virtualenv идет пользовательский код?

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

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

как только эта среда будет создана, где бы одно место их собственное:

  • файлы python?
  • статические файлы (изображения/etc)?
  • "пользовательский" пакеты, такие как те, которые доступны в интернете, но не нашли в Сырная лавка?

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

(предположим, я уже знаю, куда должны идти сами каталоги virtualenv.)

4 93
python web-deployment-project virtualenv

4 ответа:

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

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

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

72

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

довольно аккуратно, не так ли?

48

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

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

24

если вы дадите свой проект 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

The -e поставит проект в myproject/src, но связать его с myproject/lib/pythonX.X/site-packages/, поэтому любые изменения, которые вы сделаете, будут немедленно подобраны в модулях, которые импортируют его из вашего локального site-packages. Элемент #egg бит говорит Пипу, какое имя вы хотите дать пакету яиц, который он создает для вас.

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

2