Onde em um virtualenv vai o código customizado?

Que tipo de estrutura de diretório deve-se seguir ao usar virtualenv? Por exemplo, se eu estivesse construindo um aplicativo WSGI e criasse um virtualenv chamado foobar, começaria com uma estrutura de diretório como:

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

Depois de criar esse ambiente, onde alguém colocaria o seu próprio:

• arquivos python?
• arquivos estáticos (imagens / etc)?
• Pacotes "personalizados", como os disponíveis online mas não encontrados na loja de queijos?

em relação aos virtualenvdiretórios?

(Suponha que eu já saiba para onde os próprios diretórios virtualenv devem ir .)

virtualenvfornece uma instância do interpretador Python, não uma instância do aplicativo. Normalmente, você não criaria seus arquivos de aplicativo nos diretórios que contêm o Python padrão de um sistema, da mesma forma, não há necessidade de localizar seu aplicativo em um diretório virtualenv.

Por exemplo, você pode ter um projeto em que vários aplicativos usam o mesmo virtualenv. Ou você pode estar testando um aplicativo com um virtualenv que mais tarde será implantado com um sistema Python. Ou você pode estar empacotando um aplicativo autônomo em que faça sentido ter o diretório virtualenv localizado em algum lugar dentro do próprio diretório do aplicativo.

Portanto, em geral, não acho que haja uma resposta certa para a pergunta. E, uma coisa boa virtualenvé que ele oferece suporte a muitos casos de uso diferentes: não precisa haver um caminho certo.

Se você tem apenas alguns projetos de vez em quando, nada o impede de criar um novo virtualenv para cada um e colocar seus pacotes dentro:

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

A vantagem dessa abordagem é que você sempre pode ter certeza de encontrar o script de ativação que pertence ao projeto.

$ cd /foobar
$ source bin/activate
$ python 
>>> import mypackage1
>>>

Se você decidir ser um pouco mais organizado, deve considerar colocar todos os seus virtuaisenvs em uma pasta e nomear cada um deles com o nome do projeto em que está trabalhando.

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

Dessa forma, você sempre pode recomeçar com um novo virtualenv quando algo der errado e seus arquivos de projeto permanecerem seguros.

Outra vantagem é que vários de seus projetos podem usar o mesmo virtualenv, portanto, você não precisa fazer a mesma instalação repetidamente se tiver muitas dependências.

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

Para usuários que regularmente precisam configurar e desmontar o virtualenvs, faria sentido examinar o virtualenvwrapper.

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

Com o virtualenvwrapper você pode

* create and delete virtual environments

* organize virtual environments in a central place

* easily switch between environments

Você não precisa mais se preocupar com a localização do seu virtualenvs ao trabalhar nos projetos "foo" e "bar":

  /foo
    /mypackage1
      __init__.py
  /bar
    /mypackage2
      __init__.py

É assim que você começa a trabalhar no projeto "foo":

$ cd foo
$ workon
bar
foo
$ workon foo
(foo)$ python
>>> import mypackage1
>>>

Então, mudar para o projeto "bar" é tão simples quanto isto:

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

Muito legal, não é?

Como os virtuaisenvs não são realocáveis, na minha opinião é uma prática ruim colocar os arquivos do projeto dentro de um diretório virtualenv. O virtualenv em si é um artefato de desenvolvimento / implantação gerado (como um arquivo .pyc), não faz parte do projeto; deve ser fácil explodi-lo e recriá-lo a qualquer momento ou criar um novo em um novo host de implantação, etc.

Na verdade, muitas pessoas usam o virtualenvwrapper , que remove o virtualenvs real de sua consciência quase completamente, colocando-os lado a lado em $ HOME / .virtualenvs por padrão.

Se você der ao seu projeto um setup.py, pip pode importá-lo diretamente do controle de versão.

Faça algo assim:

$ virtualenv --no-site-packages myproject
$ . myproject/bin/activate
$ easy_install pip
$ pip install -e hg+http://bitbucket.org/owner/myproject#egg=proj

O -eirá colocar o projeto myproject/src, mas vinculá-lo a myproject/lib/pythonX.X/site-packages/, portanto, quaisquer alterações feitas serão coletadas imediatamente nos módulos que o importam de seu local site-packages. O #eggbit diz a pip qual nome você deseja dar ao pacote de ovos que ele cria para você.

Se você não usar --no-site-packages, tenha o cuidado de especificar que deseja que o pip seja instalado no virtualenv com a -Eopção