0

私が関わっているプロジェクトでは、Ubuntu 14.04 (Python 3.4 を使用) で compileall.compile_dir を使用して Python 製品をパッケージ化しています。pycファイル等のディレクトリをまとめて(tar.gzファイル)配布しています。ファイル名は、ファイル名の cpython-34 部分を削除するように変更されます。

Python 3.5 を搭載した Ubuntu 16.04 を実行する新しいテスト環境があり、コードを実行/テストしたいと考えています。解凍して実行すると、エラーが発生します。

$ ./configure
/usr/bin/python3: can't find '__main__' module in '/home/user/product/configure.pyz'

pyz ファイルを手動で解凍し、コマンド ラインから python を実行しようとすると、インポート後に 3.4 バイナリであるというメッセージが表示されます。代わりに、3.5 マシンでパッケージをビルドすると、3.5 マシンで完全に実行できますが、3.4 にコピーすると同じエラーが発生します。

質問は...実行/テストするには何をする必要がありますか? 私が持っていたアイデア... ある種の 3.4 互換モードで 3.5 を実行しています。3.4 をインストールします (Ubuntu 16.04 用の 3.4 パッケージが見つからないため、おそらくソースから)。3.5 の構成設定を調整してみてはいかがでしょうか。3.4 と 3.5 が機能するように、パッケージ化するときに新しい設定を提供することはできますか? いくつかのアイデアを見逃していると思いますが、解決策が何であると思うかについては尋ねたくありません。解決策が何であるかを知りたいです。

googled で pyc ファイルに関連する SO の問題をたくさん見つけたので、3.4 ファイルには互換性がないことはわかっていますが、それを使用する方法はありますか?

4

1 に答える 1

0

あなたが言及したように、コンパイルされた CPython ファイルは必ずしも異なるバージョン間で互換性があるとは限らず、プラットフォームに依存します。

私は2つの異なるアプローチを見ることができ、それぞれの解決策を提案します:

ソフトウェアの配布方法を変更する

Python wheelのようなものを使用してソフトウェアを配布する場合 (アプリケーションは Python パッケージとしてクライアント側にインストールされます)、バージョン/プラットフォームに依存しないユニバーサル ホイールを構築できます。アプリケーションの開始点は、配布されたモジュール (Python モジュールを配布する標準的な方法) によってインストールされたスクリプトです。

または、 PyInstallerまたはcx_Freeze (またはそのようなもの)を使用して、アプリケーションをスタンドアロンの実行可能ファイルとしてバンドルしてみてください。この方法では、クライアントに Python のバージョンがまったくインストールされていなくても、クライアントの Python バージョンに依存しません。アプリケーションは、対応するプラットフォーム/アーキテクチャで実行されるスタンドアロンの実行可能ファイルです。

アプリケーションを実行するマシンに同じバージョンの Python をインストールします。

最近では、コンテナー (docker など) の助けを借りて、これがはるかに簡単になっています。または、docker の使用に問題がある場合は、ソースからビルドすることをお勧めします。しかし、dockerを使用するのは簡単です。

docker pull python:3.4
docker run --rm -it -v $(pwd):/code -w /code python:3.4 python app.pyz

Python コンテナーを実行する行は、アプリケーション/構成に対してさらに調整が必要になる場合がありますが、通常はそれで十分です。

于 2016-05-17T15:28:20.563 に答える