117

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

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

この環境が作成されると、自分自身をどこに配置しますか:

  • pythonファイル？
  • 静的ファイル (画像など)?
  • オンラインで入手できるが、チーズショップでは見つからないような「カスタム」パッケージはありますか?

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

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

4

4 に答える 4

97

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

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

したがって、一般的に、この質問に対する正解は 1 つではないと思います。また、virtualenv多くの異なるユース ケースをサポートしているという利点もあります。正しい方法は 1 つだけである必要はありません。

于 2009-11-23T18:44:16.873 に答える
60

頻繁にプロジェクトが数個しかない場合は、プロジェクトごとに新しい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
>>>

定期的に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」で作業するときに、virtualenvsがどこにあるかを心配する必要はもうありません。

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

かなりきれいですね。

于 2009-11-23T14:33:35.943 に答える
31

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

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

于 2009-11-23T20:35:28.133 に答える
3

プロジェクトに を指定する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 が作成する卵パッケージに付けたい名前を pip に伝えます。

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

于 2009-11-23T16:07:43.993 に答える