問題タブ [python-wheel]

継続的インテグレーション パイプラインの一部として、リポジトリから Python ホイール ファイルを作成し、それをカスタム devpi サーバーにアップロードして、そこからホイール ファイルでテストを実行しようとしています。

私が試した方法の 1 つは、setuptools を使用して wheel ファイルを 1 行でビルドしてアップロードすることですが、これは 404 Not Found メッセージを返します。

Windows で作業している場合、私の .pypirc は C:\Users\buildbot\.pypirc にあります

プロジェクトリポジトリのルートから、次のものをビルドしてアップロードしようとしました:

ただし、ホイールは問題なく配置されてdist\proj-20141216.2.dev0-py2-none-any.whlいますが、アップロードの手順は次のようになります。

実行中のアップロード C:\var\buildminion\build_proj-dev\build\dist\proj-20141216.2.dev0-py2-none-any.whl を送信中http://pypi/root/staging

アップロードに失敗しました (404): 見つかりません

setuptools を実行registerすると、同様の結果が得られます。

カタツムリを登録していますhttp://pypi/root/staging

サーバーの応答 (404): 見つかりません

ファイルを手動でアップロードできるため、devpiサーバーが正しく実行されていることがわかります

setuptoolsuploadが機能しない理由はありますか?

また、.pypirc なしでこのアップロード機能を使用する (またはそのファイルを自動的に作成する) 方法はありますか? 将来的には、buildbot ミニオンを自動的にプロビジョニングできるようにしたいと考えています。これは、できれば避けたい余分な設定です。

これを機能させる方法がない場合は、devpi を使用して手動アップロードのスクリプトを作成できます。複数のプロジェクトの複数のバージョンで同じ CI コードが機能するようにしたいので、ホイール ファイル名と照合するコードを記述する必要がなければ簡単です。これが、 setuptools を使用することを好む理由ですupload。pipアップロード機能はありますか?

インストールするには pip が必要なため、.whl ファイルをインストールできません。pip をインストールするには、.whl ファイルを実行する必要があります。すべてのライブラリを見つけるために使用するサイト（ http://www.lfd.uci.edu/~gohlke/pythonlibs/）がexeを削除したため、pipをインストールする方法がわかりません。検索しても何も見つからなかったので、ピップを取得する別の方法があるかどうか尋ねています。ブートストラップ get-pip.py を試すと、次のようになります。

要件 pip を満たすダウンロードが見つかりませんでした。pip のディストリビューションがまったく見つかりません

TL;DR; - setuptools/distutils スクリプト ラッパー .exe entry_points は、Windows マルチプロセッシングの無限再帰をトリガーしません。Wheel のラッパー .exe entry_points が行います。以前の動作を取得するにはどうすればよいですか?

私たちの多くは、Python 2.X のマルチプロセッシング モジュールと Windows で、モジュール スクリプトを直接呼び出すときに無限再帰の問題に遭遇したことがあるでしょう。

マルチプロセッシングを使用する関数につながるライブラリのエントリ ポイントを作成したとき、エントリ ポイント スクリプトとそのラッピング .exe ファイルは、setuptools を使用してインストールしたときに Windows 上で実行可能であり、マルチプロセッシングを呼び出す関数を直接実行できました。およびプロセス オブジェクト。私のライブラリはマルチプロセッシングに依存して恥ずべき並列プログラムを高速化していたので、これは素晴らしいことでした。

bdist_wheel を使用してライブラリを共有するまでは、うまく機能していました。以前は、ビルド プロセスで .exe ラッパーとスクリプトが外側に追加されていましたが、.exe は同じ種類のラッパーではありませんでした。

私のバイナリ ファイル形式のスキルは決して優れたものではありませんが、zip 圧縮ファイルから実行可能ファイルへの何らかの変換があることを知っていたので、唯一の論理的なことを行って .exe ファイルを解凍しました。私のmingw bashシェルでさえzip / unzipを持っていなかったので、私は7zipを使いました。Wheel ファイルからインストールされた .exe ラッパーは、単純なメイン.py スクリプトを含むディレクトリに解凍されます。

それは、zip ファイルから実行された単なる Python スクリプトでした。爆発したのも不思議ではありません。

setup.py を使用して再インストールし、古いラッパー .exe を追加して、それを解凍しようとしました。見よ、7zipによって独自のファイルに抽出された.data、.pdata、.rdata、および.textセクションを含む完全なPortable Executableファイルです。2 時間後、distutils と setuptools のソース コードを調べて何が起こっているのかを調べたところ、表示されている .exe は、事前に作成されたランチャー exe にエントリ ポイント固有の Python コードを流し込むことによって作成されていることがわかりました。 Windows用。偉大な。私は以前よりも多くのことを知っています。しかし、違いが .exe ラッパーだった場合、なぜ -script.py entry_point が機能するのでしょうか?

load_entry_point特別ですか？EntryPoint.load() のラッパーであり、明示的に呼び出すために使用されます__import__。

のglobals()ドキュメントからは行き止まりのように見えます__import__が、['__name__']便利なようです。問題は、それが組み込みであり、C で実装されていることです。GitHub__import__に投稿されたミラーを読み取ろうとしましたが、現時点では私の範囲を超えており、3 つ以上の相互作用する関数に分岐しています。追跡せず、fromlist との接続を維持します。に格納されているモジュールの属性にアクセスしようとした後の次のブロックに気を取られている可能性もあります。これは、エントリ ポイント関数自体であると推測されます。__import__entry

次のコードを実行すると:

実行すると予想していたメイン関数が表示され、問題なく戻ります。

スクリプトの を含まないものに設定して、本当に__import__必要な作業を行っていますか? -m の背後にある機械がなぜランピーにならないのですか?__name____main__