10

タイトルが尋ねるように、Linux FHS に従って、Linux オペレーティング システム上で Python 仮想環境を保存するための技術的に適切な場所はどこですか?

明確な答えを可能にする別の方法を述べます:Python仮想環境の場所を提供しているデータファイルから分離することは「技術的に正しい」ですか?

注:仮想環境にはライブラリ、バイナリ、ヘッダー ファイル、およびスクリプトが含まれているため、この質問は、私が見つけることができる最も近い、既に尋ねられた質問とは異なります。

さらに厄介なことに、私はインターネットでアクセスできるサービスをサポートするコードを書く傾向があります。ただし、これは、サービスの消費者が同じサーバー上の他のプロセスであるシナリオと私のニーズを大幅に区別するものではないと思います。コメントへの応答に「web dev」風のコンテンツが含まれている場合に備えて、この詳細について言及しています。

参考までに、Linux FHS の定義として次のドキュメントを使用しています: http://www.pathname.com/fhs/pub/fhs-2.3.html

人気のある virtualenv-wrapper スクリプトが正しいアクションを示唆しているとは思えません。デフォルトでは、ユーザーのホーム ディレクトリに仮想環境を保存するためです。これは、ディレクトリがユーザー固有のファイル用であるという暗黙の概念、および「プログラムはこの場所に依存してはならない」という声明に違反しています。

/usrファイル システムのルート レベルから、 (共有可能で読み取り専用のデータ) または/srv(このシステムが提供するサービスのデータ)に傾いていますが、これをさらに決定するのに苦労しています。

頼りになるリバース プロキシの決定に私が従うとしたら、それは/usr. Nginx は通常、/usr/share/nginx または /usr/local/nginx に配置されるようにパッケージ化されていますが、FHS によると、/usr/ は読み取り専用でマウントされることになっています。開発が非常にゆっくりと行われた単一のプロジェクトに取り組んだことがなく、「読み取り専用としてアンマウント/書き込みで再マウント、アンマウント/読み取り専用として再マウント」が努力する価値があると見なされたため、これは奇妙です。

/srvは別の可能な場所ですが、「特定のサービスのデータ ファイルの場所」として示されていますが、Python 仮想環境は、サービスを提供するライブラリとバイナリに重点を置いています (この区別がなければ、.soファイルも srv にあります)。 . また、同じ要件を持つ複数のサービスが仮想環境を共有する可能性があり、これは説明の「特定の」詳細に違反します。

正しい場所を選択するのが難しいのは、仮想環境が「環境」であり、バイナリとライブラリの両方で構成されているためだと思います (ほとんどそれ自体の小さな階層のようなものです) /usr。

virtual-env/
├── bin          ~= /usr/local : "for use by the system administrator when installing software locally" 
├── include      ~= /usr/include : "Header files included by C programs"
├── lib          ~= /usr/lib : "Libraries for programming and packages"
└── share        ~= /usr/local

私の仮定と考えを述べて、Nginx が Python アプリケーションのリバース プロキシとして機能する一般的なシナリオを考えてみましょう。仮想環境とソース コード (application.py など) を、より頻繁に変更されるファイル (「静的」アセット、画像、css など) に/usr/local/service_name/使用する場合に配置するのは正しいですか?/srv

編集：明確にするために：virtualenvを使用する理由と方法を知っています。プロジェクトのレイアウトや開発環境での作業について、私は決して混乱していません。

4

1 に答える 1

6

タイトルが尋ねるように、Linux FHS に従って、Linux オペレーティング システム上で Python 仮想環境を保存するための技術的に適切な場所はどこですか?

Linux FHSは実際には標準ではなく、一連のガイドラインであることに注意してください。これは、LSB によって標準としてのみ参照されます。これは、Linux のサポートを容易にする一連の規則にすぎません。

/run、/sys、/procおよび/usr/localはすべて LFS の一部ではありませんが、ほとんどの Linux ディストリビューションで見られます。

私にとって、仮想環境を配置する明確な選択肢は です/opt。この場所は、アドオン ソフトウェア パッケージのインストール用に予約されているからです。

ただし、ほとんどの Linux ディストリビューションでは、root だけが に書き込むことができます/opt。仮想環境の主な目標の 1 つは root になることを避けることであるため、これは適切な選択ではありません。

したがって、/usr/local(通常のユーザー アカウントで書き込み可能な場合) お勧めしますが、ホーム ディレクトリにインストールしても問題はありません。

明確な答えを可能にする別の方法を述べます:Python仮想環境の場所を提供しているデータファイルから分離することは「技術的に正しい」ですか?

「あなたが提供しているデータファイル」が何を意味するのかわかりませんが、仮想環境のルールは次のとおりです。

  1. それらをソース管理に入れないでください。
  2. インストール済みパッケージのリストを維持し、これをバージョン管理に入れます。仮想環境は完全に移植可能ではないことに注意してください。
  3. 仮想環境をソース コードから分離してください。

上記を考慮して、仮想環境をソース コードから分離しておく必要があります。

Python アプリケーションへのリバース プロキシとして機能する Nginx の一般的なシナリオを考えてみましょう。仮想環境とソース コード (application.py など) を /usr/local/service_name/ の下に配置し、より動的なファイル (「静的」アセット、画像など) に /srv を使用するのは正しいですか?

静的アセットは動的ファイルではありません。用語を混乱させていると思います。

いずれにせよ、次のことを行う必要があります。

  1. そのアプリケーションを実行するためのユーザー アカウントを作成します。
  2. そのユーザーとそのユーザーだけが制御するディレクトリの下にアプリケーション ファイルを置きます。通常、これはディレクトリですが、これを. 標準の命名形式で、仮想環境をこのディレクトリのサブセットとして配置します。たとえば、私は を使用します。/home/username/services/servicenameenv
  3. すべてのメディア ファイル、 cssファイルなどの静的アセットを、フロント エンド サーバーが読み取り可能なディレクトリに配置します。したがって、通常はwwwディレクトリまたはディレクトリを作成しますpublic_html。
  4. ファイルを更新できるように、このアプリケーション用に作成したユーザー アカウントにこのアセット ディレクトリへの書き込みアクセス権があることを確認してください。プロキシ サーバーには、このディレクトリに対する実行権限を付与しないでください。これを行うには、ディレクトリのグループをプロキシ サーバー ユーザーのグループと同じに変更します。これを考えると、このディレクトリを/home/username/orの下に置き/services/servicenameます。
  5. プロセス マネージャーを使用してアプリケーションを起動し、アプリケーション コードを実行するときに、プロセス マネージャーがユーザーをステップ 1 で作成したユーザーに切り替えることを確認します。

最後に、 DOCUMENT YOUR PROCESS and AUTOMATE ITはいくら強調してもしきれません。

于 2014-06-22T04:31:54.327 に答える