Где в virtualenv идет код?

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

Тогда переключение на "bar" проекта так же просто:

$ cd ../bar
$ workon bar
(bar)$ python
>>> import mypackage2
>>>

Довольно аккуратный, не так ли?

Ответ 3

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

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

Ответ 4

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

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