Куди у virtualenv іде спеціальний код?

Якій структурі каталогів слід керуватися при використанні virtualenv? Наприклад, якби я будував додаток WSGI і створював virtualenv під назвою, 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що він підтримує безліч різних випадків використання: не потрібно бути одним правильним способом.

Якщо у вас є так часто кілька проектів настільки часто, ніщо не заважає вам створити новий 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, коли справи йдуть не так, а ваші файли проекту залишаються в безпеці.

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

Досить акуратно, чи не так?

Оскільки virtualenvs не є переїздом, на мою думку, неправильно розміщувати файли проектів у каталозі virtualenv. Сам virtualenv - це створений артефакт розробки / розгортання (на зразок файлу .pyc), а не частина проекту; його слід легко зруйнувати та відтворити в будь-який час або створити новий на новому хості розгортання тощо.

Насправді багато людей використовують virtualenvwrapper , який практично повністю видаляє фактичні virtualenvs з вашої обізнаності, розміщуючи їх усі поруч у $ 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Трохи говорить Піп , що ім'я , яке ви хочете дати пакет яєць він створює для вас.

Якщо ви не використовуєте --no-site-packages, будьте обережні, щоб вказати, що ви хочете, щоб файл встановив у virtualenv -Eпараметр