web-dev-qa-db-ja.com

カスタムコードはvirtualenvのどこに行きますか？

virtualenvを使用する場合、どのようなディレクトリ構造に従う必要がありますか？たとえば、WSGIアプリケーションを構築してfoobarというvirtualenvを作成した場合、次のようなディレクトリ構造から始めます。

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

この環境が作成されたら、どこに独自の環境を配置しますか：

  • pythonファイル？
  • 静的ファイル（画像/など）？
  • オンラインで入手できるがチーズショップにはない「カスタム」パッケージ？

virtualenvディレクトリに関連して？

（私がすでに知っていると仮定します virtualenvディレクトリ自体が行くべき場所 。）

pythonprojectvirtualenv
100
Phillip B Oldham

virtualenvは、アプリケーションインスタンスではなくpythonインタープリターインスタンスを提供します。通常、システムのデフォルトPythonを含むディレクトリ内にアプリケーションファイルを作成することはありません。同様に検索する必要はありません。 virtualenvディレクトリ内のアプリケーション。

たとえば、同じvirtualenvを使用する複数のアプリケーションがあるプロジェクトがあるとします。または、後でシステムPythonでデプロイされるvirtualenvでアプリケーションをテストしている場合があります。または、virtualenvディレクトリをアプリディレクトリ内のどこかに置くことが理にかなっているスタンドアロンアプリをパッケージ化する場合があります。

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

82
Ned Deily

頻繁に少数のプロジェクトしかない場合、各プロジェクトに新しい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
>>>

次に、プロジェクト「バー」への切り替えは次のように簡単です。

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

きれいですよね？

53
Maik Röder

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

実際、多くの人が virtualenvwrapper を使用します。これにより、実際のvirtualenvが認識からほぼ完全に削除され、デフォルトですべてが$ HOME/.virtualenvsに並んで配置されます。

28
Carl Meyer

プロジェクトに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を使用しない場合は、-Eオプションを使用してpipをvirtualenvにインストールするように指定するよう注意してください

2
jcdyer