車輪の上のパイソン

Pythonのパッケージシステムインフラストラクチャは、開発者とシステム管理者の両方から長い間批判されてきました。 長い間、コミュニティ自体でさえ、特定のケースごとにどの器具を使用するかについて合意できませんでした。 Distutils、setuptools、distribute、distutils2は、基本的な配布メカニズムとして既に存在し、virtualenv、buildout、easy_install、およびpipは、この混乱をすべて管理するための高レベルのツールとして存在します。



setuptools以前は、主な配布形式はソースファイルまたはWindows用のバイナリMSI配布でした。 Linuxでは、 bdist_dumb



とbdist_rpm



は最初は壊れていましたが、これはRed Hatベースのシステムでのみ機能しました。 しかし、 bdist_rpm



さえ、人々が使用を開始するには十分にbdist_rpm



しませんでした。



数年前、 PJEはdistutilsを改善し、Pythonパッケージにメタデータを追加するために、setuptoolsとpkg_resourcesの混合物を提供することにより、この問題を修正しようとしました。 これに加えて、彼はそれらをインストールするeasy_installユーティリティを書きました。 メタデータをサポートする配布形式がないため、「卵」形式が提供されていました。



Python eggは、pythonパッケージと必要なメタデータを含む通常のzipアーカイブです。 多くの人がたまに卵を意図的に収集したことはないでしょうが、メタデータの形式はまだ健在です。 そして、誰もがsetuptoolsを使用してプロジェクトを展開しています。



残念ながら、しばらくして、コミュニティは分裂し、その一部はバイナリ形式、特に「卵」の消滅を宣言しました。 その後、easy_installを置き換えるpipは、egg形式の受け入れを停止しました。



それからもう少し時間が経ち、バイナリパッケージの拒否が不便を引き起こし始めました。 人々はますますクラウドサーバーに展開し始め、各マシンでC-shnyライブラリを再コンパイルする必要性はあまり喜ばしくありません。 当時の「卵」はあいまいだったので（私はそう思う）、それらは新しいPEPでやり直され、「 ホイール 」と呼ばれました。



さらに、すべてのアクションがvirtualenv環境で行われると想定されています 。

どんなホイール？

簡単なものから始めましょう。 「ホイール」とは何ですか、また「卵」とどう違うのですか？ どちらの形式もzipファイルです。 主な違いは、卵は開梱せずにインポートできるのに対し、ホイールは開梱する必要があることです。 車輪を輸入不可にする技術的な理由はありませんが、直接輸入のサポートは計画されていません。



もう1つの違いは、「卵」にはコンパイル済みのバイトコードが含まれるのに対し、「ホイール」には含まれないことです。 これの主な利点は、libpythonを介してリンクされたモジュールを配布する必要があるまで、Pythonのバージョンごとに個別のホイールを作成する必要がないことです。 Python 3の新しいバージョンでは、安定したABIを使用していますが、これもすでに強化されています。



ただし、ホイール形式にも問題がないわけではなく、その一部は「卵」から継承しています。 たとえば、Linuxでのバイナリディストリビューションは、Python自体がさまざまな形式でLinuxでコンパイルされることと、モジュールがさまざまなシステムライブラリにリンクするという2つの欠点があるため、ほとんどの場合まだ受け入れられません。 最初の問題は、Python 2：USC2とUSC4の互換性のないバージョンの共存が原因です。 ABIは、コンパイルモードに応じて変わります。 現在、ホイール（私が知る限り）には、ライブラリが関連付けられているUnicodeモードに関する情報が含まれていません。 別の問題は、Linuxディストリビューションの互換性が私たちが望んでいるよりも低いことであり、状況によっては、あるディストリビューション用にコンパイルされたアセンブリが他のディストリビューションで動作しないことがあります。



これはすべて、一般的に言えば、現時点では、バイナリ「ホイール」をさまざまなシステムとの互換性がないとしてPyPIにアップロードできないという事実に変換されます。



これらすべてに加えて、ホイールは、バイナリパッケージと純粋なpythonコードを含むパッケージという2つの極端な点のみを認識します。 バイナリパッケージは、Pythonブランチ2.xに固有です。 これは、2.xサイクルが終わりに近づいているため、大きな問題ではないように思われます。また、2.7でのみ収集されたパッケージは、長い間十分です。 しかし、Python 2.8が突然登場した場合、このパッケージはPythonのバージョンに依存しないが、バイナリが含まれているため、アーキテクチャに依存せざるを得ないというのは興味深いことです。



そのようなパッケージの存在を正当化する唯一のケースは、CFFIからctypesでロードされた分散ライブラリが含まれている場合です。 このようなライブラリはlibpythonを介してリンクされておらず、言語実装から独立しています（pypyでも使用できます）。



しかし、明るい面があります。独自の同種のインフラストラクチャでのバイナリホイールの使用を禁止するものはありません。

ホイールアセンブリ

これで、ホイールとは何かがわかりました。 独自の「ホイール」の作り方 独自のライブラリから組み立てるのが最も簡単なプロセスです。 必要なのは、最新バージョンのsetuptools



とwheel



ライブラリだけです。 両方がインストールされると、次のコマンドで「ホイール」が組み立てられます。

 $ python setup.py bdist_wheel
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ホイールはパッケージディレクトリに作成されます。 ただし、注意が必要なことが1つあります。バイナリの配布です。 デフォルトでは、アセンブルされた「ホイール」（setup.pyでバイナリステップが使用されていないことを前提としています）は、純粋なPythonコードで構成されています。 これは、パッケージの一部として.so



、 .dylib



または.dll



を配布した場合でも、結果の「ホイール」はプラットフォームに依存しないように見えることを意味します。



この問題を解決するには、setuptoolsからDistributionを手動で実装し、純度フラグをfalse



スローしfalse



。

 import os from setuptools import setup from setuptools.dist import Distribution class BinaryDistribution(Distribution): def is_pure(self): return False setup( ..., include_package_data=True, distclass=BinaryDistribution, )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ホイール設定

最新バージョンのpipを使用して、「ホイール」は次のように設定されます。

 $ pip install package-1.0-cp27-none-macosx_10_7_intel.whl
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、依存関係はどうですか？ いくつかの困難があります。 通常、パッケージの要件の1つは、インターネットに接続していなくてもインストールできることです。 幸いなことに、pipを使用すると、インデックスからの読み込みを無効にし、インストールする必要があるすべてのものを含むディレクトリをインストールできます。 必要なバージョンのすべての依存関係のホイールがある場合は、次を実行できます。

 $ pip install --no-index --find-links=path/to/wheels package==1.0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これ1.0



パッケージpackage



バージョン1.0



仮想環境にインストールされます。

中毒用ホイール

さて、しかし、すべての依存関係に.whlがない場合はどうでしょうか？ 理論上のピップにより、 wheel



コマンドを使用してこの問題を解決できます。 これは次のように動作します：

 pip wheel --wheel-dir=path/to/wheels package==1.0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコマンドは、指定したフォルダーに依存するパッケージのすべてのパッケージをアンロードします。 しかし、いくつかの問題があります。

1つは、チームには現在、既に「ホイール」である依存関係をアンロードしないバグがあるということです。 そのため、PyPIでホイール形式の依存関係が既に利用可能な場合、ロードされません。



これは、ダウンロードしたホイールをキャッシュから手動で移動するシェルスクリプトによって一時的に解決されます。

 #!/bin/sh WHEEL_DIR=path/to/wheels DOWNLOAD_CACHE_DIR=path/to/cache rm -rf $DOWNLOAD_CACHE_DIR mkdir -p $DOWNLOAD_CACHE_DIR pip wheel --use-wheel -w "$WHEEL_DIR" -f "$WHEEL_DIR" \ --download-cache "$DOWNLOAD_CACHE_DIR" package==1.0 for x in "$DOWNLOAD_CACHE_DIR/"*.whl; do mv "$x" "$WHEEL_DIR/${x##*%2F}" done
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目の問題はもう少し深刻です：PyPIにない場合、pipはどのようにして独自のパッケージを見つけるのですか？ そうです、何もありません。 この場合、ドキュメントでは、 pip wheel package



ではなく、 pip wheel -r requirements.txt



を使用することを推奨していpip wheel -r requirements.txt



。ここで、 requirements.txt



には必要な依存関係がすべて含まれています。

DevPIを使用したパッケージの構築

依存関係の問題に対するこのような一時的な解決策は、単純な状況では非常に当てはまりますが、相互に依存する内部Pythonパッケージが多数ある場合はどうでしょうか。 この設計はすぐに崩壊します。



幸いなことに、昨年、Holker KrekelはDevPIと呼ばれるこの災害に対するソリューションを作成しました。これは基本的に、PyPIでpipの動作をエミュレートするハックです。 DevPIはコンピューターにインストールされると、PyPIの前に透過プロキシとして機能し、pipがローカルリポジトリからパッケージをインストールできるようにします。 さらに、PyPIからダウンロードされたすべてのパッケージは自動的にキャッシュされるため、ネットワークを切断しても、これらのパッケージはインストールできます。 そして、最終的に、パブリックインデックスに保存されているパッケージと同じ方法でそれらを参照するために、ローカルサーバーに独自のパッケージをアップロードすることが可能になります。



ローカルのvirtualenvにDevPIをインストールすることをお勧めしdevpi-server



。 devpi



、 PATH



にdevpi-server



とdevpi



へのリンクを追加します。

 $ virtualenv devpi-venv $ devpi-venv/bin/pip install --upgrade pip wheel setuptools devpi $ ln -s `pwd`/devpi-venv/bin/devpi ~/.local/bin $ ln -s `pwd`/devpi-venv/bin/devpi-server ~/.local/bin
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、 devpi-server



を起動するために残り、手動で停止するまで機能します。

 $ devpi-server --start
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

起動後、一度初期化する必要があります。

 $ devpi use http://localhost:3141 $ devpi user -c $USER password= $ devpi login $USER --password= $ devpi index -c yourproject
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私は「自分用」にDevPIを使用しているため、DevPIのユーザー名とシステムのユーザー名は同じです。 最後のステップで、プロジェクトの名前でインデックスが作成されます（必要に応じて、複数作成できます）。



pipをローカルリポジトリにリダイレクトするには、環境変数をエクスポートできます。

 $ export PIP_INDEX_URL=http://localhost:3141/$USER/yourproject/+simple/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコマンドをpostactivate



スクリプトに入れて、誤ったインデックスからの偶発的なロードを防ぎます。



ローカルのDevPIに独自のホイールを配置するには、 devpi



ユーティリティをdevpi



ます。

 $ devpi use yourproject $ devpi upload --no-vcs --formats=bdist_wheel
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

--no-vcs



は、バージョン管理システムを識別しようとするマジックを無効にし、最初にいくつかのファイルを移動します。 私のプロジェクトでは、VCSに含まれていないファイル（バイナリなど）が配布されているため、これは必要ありません。



最終的に、PyPIが拒否し、DevPIがsetup.py resease



誤ってコードをオーバーロードしないように、setup.pyファイルを分割することを強くお勧めします。 これを行う最も簡単な方法は、誤ったPyPI分類子を追加することです。

 setup( ... classifier=['Private :: Do Not Upload'], )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まとめ

これで、すべてが内部依存関係を使用し、独自の「ホイール」を組み立て始める準備ができました。 表示されたらすぐに、アーカイブし、別のサーバーにダウンロードして、別のvirtualenvにインストールできます。

pip wheel



が既存のwheelパッケージを無視しなくなると、プロセス全体が少し簡単になります。 それまでの間、上記のシェルスクリプトは最悪の解決策ではありません。

「卵」と比較して

ホイール形式は、eggよりも魅力的です。 開発がより活発になり、PyPIがサポートを追加し始め、ユーティリティがそれを使い始めるので、それが最良のソリューションのように見えます。 「卵」はこれまでのところeasy_installでのみサポートされていますが、ほとんどは長い間pipに切り替えました。



Zopeコミュニティはまだ最大の卵ベースおよびビルドアウトベースのコミュニティだと思います。 そして、「卵」に基づいたソリューションがあなたの場合に適用できるなら、それを適用すべきだと思います。 多くの人は卵をまったく使用せず、virtualenvを作成し、アーカイブして別のサーバーに送信することを好みます。 異なるサーバーには異なるライブラリパスがある可能性があるため、このような展開の場合、wheelsが最適なソリューションです。 virtualenvのビルドサーバーで.pyc



ファイルが作成され、これらのファイルに特定のファイルパスが含まれるという問題がありました。 wheel .pyc



を使用すると、仮想環境へのインストール後に作成され、自動的に正しいパスが設定されます。



だから今、あなたはそれを持っています。 車輪の上のPython。 そして、それは一種の機能であり、おそらく時間を費やす価値があります。