サンプルシナリオは次のとおりです。
新しいディレクトリ、たとえば /myapps から開始します。別の (コンパイル済みまたはソースの) Python を ./usr/bin (インストール ディレクトリを基準とし、システムの /usr/bin ではない) にインストールし、このカスタム Python にさまざまな egg をインストールします。これは、おそらく buildout などを使用して実行できます。
同じ OS バージョンを持つ別のユーザーが、正確なフォルダー構造を維持しながらフォルダーを rsync すると、他のユーザーと同じように Python を使用できるようになります。本当に何かを再度インストールする必要がありますか?
Linux パッケージ マネージャーのほとんどは、/usr と類似した /myapps で、つまり、ファイルを保存する場所に関するデフォルトの規則でこのように動作すると考えていました。Gentoo インストールのように最適化する場合を除き、コンパイルは必須ではありません。言い換えると、ほとんどのパッケージ マネージャーが行うことは次のようになります。
1) 要件チェック
2) コンパイル済みのものを /usr/lib /usr/bin などの標準的な場所にコピー/貼り付けします。
3) メニューを更新する
最初のマシンにおけるいくつかの前提条件:
すべてをこのディレクトリ内にインストールし、外部にはインストールしないでください。通常のユーザーとして実行され、 sudo は使用されません。
Windows では、通常のファイル システムの概念のようにはよくわからないレジストリなどのため、これは難しいと思います。しかし、*nix では、これは同じように簡単に機能するのでしょうか?
答え1
それは完全に可能です (ただし、通常は、virtualenv を作成し、virtualenv ルート全体をバンドルすることで同じ結果が得られます)。一部の Python パッケージが外部ライブラリを必要とし、他のユーザーがそれらをインストールしていない場合は問題が発生します (そのため、通常は virtualenv と pip bundle/pip freeze を使用して行います)。
パッケージ マネージャーは、いわゆるインストール スクリプトを実行します。これらには任意のコードを含めることができますが、通常は必要なユーザー/グループを追加し、他の構成を編集します (構成内の行を「インストール」できないため、すべての *.conf を *.conf.d に分割する動きは少し役立ちますが、まだ完了にはほど遠いです)。ただし、ほとんどの Python パッケージでは問題ありません。