7

私はすでにpipとvirtualenvを使用しています（実際には、SVNリポジトリ、svn：externalsの賢明な使用法、および動的sys.pathを介した適切に編成された組み合わせを好む場合があります）。

しかし、今回は新しいサーバーのインストールのために、私は正しい方法で物事をやりたいと思っています。

だから私はpipのインストールページに行き、それは言う：

すべてのvirtualenvにはpipが自動的にインストールされるため、pipを使用するための推奨される方法はvirtualenv内です。これには、rootアクセスや、システムのPythonインストールの変更は必要ありません。[...]

次に、virtualenvのインストールページに移動すると、次のように表示されます。

virtualenvは、pip install virtualenvを使用してインストールするか、最新の開発バージョンをpip install virtualenv==devを使用してインストールできます。easy_installを使用することもできます[...]

もちろん、pipはeasy_installを置き換えることになっています:)

確かに、どちらもインストールのすべての代替方法を説明しています。

しかし...どちらが最初に行くべきですか？ そして、私はシステム全体のピップを好むべきかどうか？

熟考する主な理由はわかりますが、他にもあるかもしれません

  • ボックスのすべてのユーザーの生活を促進したいですか、それともこれはいくつかのサービスを実行している1人のユーザーを対象としたサーバーですか？

誰もが仮想環境を利用できるようにしたい場合は、システム全体のpipをインストールするだけです（たとえば、ubuntusudo aptitude install python-pipを使用して、それを使用してvirtualenvをインストールしますsudo pip install virtualenv）。

別の理由を編集して熟考してください： virtualenvwrapperのインストール手順（ドキュメントではありません）は次のように述べています：

注virtualenvwrapperを使用するには、virtualenvを個別にインストールする必要があります。

そこで「別々に」が何を意味するのか正確にはわかりません（私は気づきませんでした）。

そうでなければ、どちらが最初に行くべきですか、そしてそれは本当に違いを生むかどうか？

関連している：

最も近い質問（および回答）は、次の最初の質問（特に、@ elarsonの回答を参照）です。2番目の質問は非常に複雑に見えます。

しかし、私の質問に完全に答えることはできないと感じています：システム全体とローカルですが、pipまたはvirtualenvを最初に実行する必要があります（そして、なぜ最初にそれぞれを互いに送信するのですか!!!）

4

3 に答える 3

6

tl;dr回答は最初にVirtualEnvになります。Pythonバージョン2.xおよび3.x用にそれぞれ2つ持つことができます

[編集]

インストールするかどうかは本当に疑わしいです（インストールはありません。スクリプトをダウンロードして実行するだけです）VirtualEnvシステム全体/ユーザーごとでも問題になります。VirtualEnvを使用することの全体的なポイントは、1つのプロジェクトのライブラリが互いに競合しないように、分離された開発サンドボックスを作成することです。たとえば、Beautiful-soupバージョン<4.xを使用するPython 2.xプロジェクトと、2つの異なる仮想環境でBeautiful-soupバージョン4.0を使用するPython3.xプロジェクトを実行できます。

システムでVirtualEnvスクリプトを取得する方法は実際には重要ではありません。スクリプトを取得し、pipがVirtualEnv内に自己完結している場合は、最初にVirtualEnvを取得するのが理にかなっています。また、Pythonを使用すると、多くのプロジェクトが作成されます。それぞれについて、仮想環境を作成し、pipを介して依存関係をインストールすることをお勧めします。後で「pipfreeze>requirements.txt」を実行してから「pipinstallrequirements.txt」を実行して、2つのシステム（開発と本番など）に正確なライブラリを複製することができます...

于 2012-05-09T15:46:55.570 に答える
1

決定的な解決策はまだ決まっていませんが、@ nutjobのコメントに一部基づいて現在進行中です（いいえ、当面はビルドアウトに切り替えていませんが、後でしばらく時間がかかります！）

私は、非常に多くのdjangoアプリケーションを備えた大きくて強力なサーバーを持っています。私は主にgunicorn+supervisordを使用しています。

これらの要件は次のことを示していますが、設定が少し異なるとおそらく異なるでしょう。

  1. コード/機能の類似性に基づいて、これらのアプリケーションをクラスターに論理的に編成しました。各クラスターには、同じバージョンの一般的なPythonライブラリ（pylibmc、pillowなど）が含まれている可能性があります。
  2. クラスタごとに1つずつ、数人のユーザーを作成します
  3. ユーザーごとに、virtualenv.pyをダウンロードして実行することにより、virtualenvをインストールします（ユーザーと同じ名前で、自分で選択します）python virtualenv.py VIRTUALENVNAME。virtualenvラッパーをインストールしません
  4. そのユーザー.bashrcを編集して、virtualenvがすぐに読み込まれるようにします
  5. 共通パッケージをpipでインストールしますが、より具体的なパッケージはsys.pathを介して直接追加されます。これにより、必要なライブラリのほとんどをすべて運ぶフォルダー/バージョン管理プロジェクト構造により、さらに高速な展開が可能になります。これはより明確で、展開が速く、編集が簡単だと思います。個々のケースのマイレージは異なる場合があります。

これは、各ユーザーが独自の単一のvirtualenvを持っていることを意味します。

最初からやり直す必要がある場合は、おそらくビルドアウトまたは同様のソリューションに移行します（supervisorとvirtualenvを組み合わせたときに何が起こるかについては大ファンではありません）が、今はこれにかなり満足しています...

于 2012-05-15T15:32:30.620 に答える
1

1つの半分、別の6ダース。（それを沈めましょう。ハハ。）

しかし、もっと真剣に、あなたは正直にあなたのシステムに複数のユーザーを持っていますか？最近では、Linuxホストでさえ単一のユーザー向けである傾向があり、複数のユーザーIDがある場合、それらはさまざまな隔離されたユーザーIDの下で複数のプロセスを実行するサーバーになる傾向があります。それを考えると、すべてのユーザーの生活を楽にすることはそれほど重要ではありません。

一方、Pythonを使用する複数のサービスには、要件が競合する場合があります。必要なバージョンのにまで要約される場合があるため、まれですpip。それを考えると、Pythonの元の準インストールを作成するために、virtualenvのグローバルインストールを好む傾向があります。

それでも、もう1つのアイデアを指摘したいと思います。Buildout、http ：//www.buildout.org/

Buildoutはvirtualenvと同じことを行いますが、著しく異なるアプローチを取ります。さまざまな卵が何であるか、それらがどのように接続されるかをリストするビルドアウト構成ファイル（buidout.cfg）を作成し、特殊な状況（Djangoデプロイメント、Buildbotサーバー、Plone Webサイトなど）を設定する「ビルドアウトレシピ」の設定を指定します。 Google App Engineアプリなど）。

次に、システムPythonを使用してビルドアウトをブートストラップして実行すると、virtualenvのような分離されたセットアップが生成されます。

しかし、最良の部分は、繰り返し可能です。同じbuildout.cfgものを別のホストに持っていき、同じセットアップを取得できます。これをvirtualenvで行うのははるかに困難です！

于 2012-05-09T15:38:39.797 に答える