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ディレクトリをアプリディレクトリ自体のどこかに配置することが理にかなっている可能性があります。

ですから、一般的には、質問に対する正しい答えは1つではないと思います。そして、良い点virtualenvは、それが多くの異なるユースケースをサポートしているということです：1つの正しい方法である必要はありません。

たまに少数のプロジェクトしかない場合でも、プロジェクトごとに新しい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
>>>

もう少し整理する場合は、すべてのvirtualenvを1つのフォルダーに入れて、作業中のプロジェクトにちなんでそれぞれに名前を付けることを検討してください。

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

このようにすると、問題が発生したときにいつでも新しいvirtualenvからやり直すことができ、プロジェクトファイルの安全性が維持されます。

もう1つの利点は、いくつかのプロジェクトで同じvirtualenvを使用できるため、依存関係が多い場合に何度も同じインストールを行う必要がないことです。

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

virtualenvを定期的に設定および破棄する必要があるユーザーにとっては、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」で作業するとき、virtualenvがどこにあるかを心配する必要はありません。

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

かなりすっきりしていますね。

virtualenvは再配置可能ではないため、私の意見では、virtualenvディレクトリ内にプロジェクトファイルを配置することはお勧めできません。virtualenv自体は、プロジェクトの一部ではなく、生成された開発/デプロイメントアーティファクト（一種の.pycファイルのようなもの）です。それを吹き飛ばしていつでも再作成したり、新しいデプロイホストで新しいものを作成したりするのは簡単です。

実際、多くの人がvirtualenvwrapperを使用します。これにより、実際のvirtualenvが認識からほぼ完全に削除され、デフォルトですべてが$ 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ビットは、作成するeggパッケージに付ける名前をpipに指示します。

を使用しない場合は--no-site-packages、pipを-Eオプションでvirtualenvにインストールするように指定するように注意してください