Nuitka
1.0.0
このドキュメントは、 Nuitkaの使用を開始するときに最初に読むことをお勧めします。このページでは、ライセンスの種類、使用例、要件、クレジットなど、 Nuitka の基礎について詳しく学習します。
目次
要件
使用法
チュートリアル Windows でのセットアップとビルド
使用例
微調整
典型的な問題
ヒント
編集報告書
パフォーマンス
サポートされていない機能
Nuitka はPythonコンパイラーです。 Python で書かれています。これは、Python インタープリターのシームレスな置き換えまたは拡張であり、 Python 2 (2.6、2.7) および Python 3 (3.4 ～ 3.13) がその Python バージョンで実行されるときに、Python 2 (2.6、2.7) および Python 3 (3.4 ～ 3.13) が持つすべての構造をコンパイルします。
次に、コンパイルされていないコードとコンパイルされたコードを、非常に互換性のある方法で一緒に実行します。
すべての Python ライブラリ モジュールとすべての拡張モジュールを自由に使用できます。
Nuitka は Python モジュールを C レベルのプログラムに変換し、 libpythonと独自の静的 C ファイルを使用して CPython と同じ方法で実行します。
すべての最適化は、不必要なオーバーヘッドを回避することを目的としています。互換性を削除することを目的としたものはありません。ただし、標準 Python のすべてのバグがエミュレートされるわけではない、わずかな改善が時折行われます。たとえば、より完全なエラー メッセージが表示されますが、それさえ無効にする完全互換モードがあります。
Nuitkaのスムーズな動作を確保するには、次のコンポーネントを含むシステム要件に従ってください。
Cコンパイラ
パイソン
オペレーティング·システム
建築
C11 をサポートする C コンパイラ、または C++03 用の C++ コンパイラが必要です [1]。
現在、これは、次のコンパイラのいずれかを使用する必要があることを意味します。
Windows 上の MinGW64 C11 コンパイラは、gcc 11.2 以降に基づいている必要があります。使用可能な C コンパイラーが見つからない場合は、自動的にダウンロードされます。これは、Nuitka がアップグレードも行うため、推奨されるインストール方法です。
Windows 上の Visual Studio 2022 以降 [2]。最良の結果を得るための英語言語パック (Nuitka はガベージ出力をフィルタリングして除去しますが、英語のみを対象とします)。インストールされている場合はデフォルトで使用されます。
他のすべてのプラットフォームでは、少なくともバージョン 5.1 のgccコンパイラ、およびそれ未満のバージョンでは少なくともバージョン 4.4 のg++コンパイラが代替として使用されます。
macOS X およびほとんどの FreeBSD アーキテクチャ上のclangコンパイラ。
Windows では、Visual Studio インストーラーによって提供されている場合、Windows のclang-clコンパイラーを使用できます。
| [1] | この C11 のサポートは、gcc 5.x 以降、または任意の Clang バージョンで提供されます。 古い MSVC コンパイラはまだそれを行っていません。ただし、回避策として、Python 3.10 以前では、C++03 言語標準が C11 と大幅に重複しているため、代わりにそれが使用されます。 |
| [2] | https://www.visualstudio.com/en-us/downloads/download-visual-studio-vs.aspx から無料でダウンロードします (コミュニティ エディションは問題なく動作します)。 最新バージョンを推奨しますが、必須ではありません。一方、Windows 10 より前のバージョンをサポートする必要はなく、問題なく機能する可能性がありますが、これらの構成のサポートは商用ユーザーのみが利用できます。 |
Python 2 (2.6、2.7) およびPython 3 (3.4 ～ 3.13) がサポートされています。このリストにない安定した Python リリースが存在する場合は、現在開発中であり、追加される予定ですのでご安心ください。
重要
Python 3.4 とそのバージョンのみの場合、コンパイル時の依存関係として他の Python バージョンが必要です。
Nuitka 自体は、リストされているすべてのバージョンと完全な互換性がありますが、内部で使用されるツールとしての Scons は互換性がありません。
これらのバージョンでは、Python2 または Python 3.5 以降もインストールする必要がありますが、これはコンパイル時にのみインストールされます。これは、Nuitka と同じ Python バージョンをサポートしない Scons (C コンパイルを調整する) で使用するためのものです。
また、Windows ではclcache動作しないため Python2 は使用できません。Python 3.5 以降をインストールする必要があります。
Nuitka はこれらの必要な Python バージョンを (たとえば Windows ではレジストリ経由で) 見つけます。それらがインストールされている限り、それに気づく必要はありません。
別の Python に特定のパッケージがインストールされている場合、他の機能が利用できるようになってきています。たとえば、 zstandardパッケージがインストールされている別の Python が見つかった場合、onefile 圧縮は Python 2.x で機能します。
バイナリを他のマシンに移動する
作成されたバイナリは、 --standaloneおよび--onefileオプションを使用して、Python のインストールとは独立して実行可能にすることができます。
バイナリファイル名の接尾辞
作成されたバイナリには、Windows では.exeサフィックスが付いています。他のプラットフォームでは、スタンドアロン モードのサフィックスや.bin接尾辞はなく、自由に削除または変更したり、 -oオプションで指定したりできます。
アクセラレーション モードのサフィックスは、元のスクリプト名とバイナリ名が衝突しないようにするために追加されているため、元のソース ファイルを破壊することなくバイナリを安全に上書きできます。
CPython、Anaconda Python、または Homebrew である必要があります
Nuitka を実行するには、「CPython」と呼ばれる標準の Python 実装が必要です。これは、Nuitka の実装の詳細と密接に関係しているためです。
Windows アプリ ストアからは使用できません
Windows アプリ ストアの Python は確実に動作しないことが知られており、チェックされています。
macOS では pyenvは使用できません
macOSの「pyenv」は動作しないことが知られています。自己コンパイルされた Python インストールには、代わりに Homebrew を使用してください。ただし、これらのプラットフォームではスタンドアロン モードのパフォーマンスが低下し、古い macOS バージョンとの下位互換性がなくなることに注意してください。
サポートされているオペレーティング システム: Linux、FreeBSD、NetBSD、macOS、および Windows (32 ビット/64 ビット/ARM)。
他の人も同様に機能します。移植性は一般に良好であると予想されますが、たとえば Nuitka の内部 Scon の使用法を調整する必要があるか、フラグを渡す必要がある場合があります。必ず Python と C コンパイラのアーキテクチャを一致させてください。一致しないと、不可解なエラー メッセージが表示されます。
サポートされているアーキテクチャは、x86、x86_64 (amd64)、arm であり、おそらくさらに多くのアーキテクチャです。
Nuitka は一般にハードウェア固有のものを使用しないため、他のアーキテクチャもそのまま動作すると予想されます。これらは、テストされ、良好であることがわかっているものにすぎません。フィードバックは大歓迎です。一般に、Debian がサポートするアーキテクチャは優れていると考えられ、テストも行われます。
Nuitka を実行する推奨方法は、使用している Python インタプリタを確実に確認するための<the_right_python> -m nuitkaです。これにより、Nuitka の内容との一致が容易になります。
環境変数を変更せずにソース チェックアウトまたはアーカイブから Nuitka を実行する次善の方法は、最も注目すべき点は、Nuitka ではPYTHONPATHをまったくいじる必要がないことです。環境を変更せずに、 nuitkaスクリプトとnuitka-runスクリプトを直接実行するだけです。便宜上、 binディレクトリをPATHに追加することもできますが、この手順はオプションです。
また、適切なインタプリタで実行したい場合は、必ず<the_right_python> bin/nuitka実行してください。
適切な通訳者を選択してください
SyntaxErrorが発生した場合は、コンパイル中のプログラムに対して間違ったインタプリタを選択したことは間違いありません。
Nuitka には、何ができるかを出力する--helpオプションがあります。
nuitka --ヘルプ
nuitka-runコマンドはnuitkaと同じですが、デフォルトが異なります。 Python スクリプトをコンパイルして直接実行しようとします。
nuitka-run --ヘルプ
この異なるオプションは--runで、最初の非オプションの後の引数を作成されたバイナリに渡すため、プレーンなpython動作に多少似ています。
ほとんどのシステムでは、Nuitka のダウンロード ページにパッケージがあります。ただし、上で説明したようにソース コードからインストールすることもできますが、他の Python プログラムと同様に、通常のpython setup.py installルーチンを介してインストールすることもできます。
GitHub ワークフローとの統合については、統合を非常に簡単にする Nuitka-Action を使用する必要があることに注意してください。ただし、ローカル コンパイルから始める必要がありますが、Nuitka を使用したクロスプラットフォーム コンパイルではこれが最も簡単です。
Nuitka は、Apache License バージョン 2.0 に基づいてライセンスされています。ライセンスに準拠する場合を除き、これを使用することはできません。
ライセンスのコピーは http://www.apache.org/licenses/LICENSE-2.0 で入手できます。
適用される法律で義務付けられている場合または書面による同意がない限り、ライセンスに基づいて配布されるソフトウェアは、明示または黙示を問わず、いかなる種類の保証や条件もなく、「現状のまま」で配布されます。ライセンスに基づく許可と制限を規定する特定の言語については、ライセンスを参照してください。
これは、何もインストールされていない場合の基本的な手順ですが、もちろん、部品がある場合はスキップしてください。
https://www.python.org/downloads/windows から Python をダウンロードしてインストールします。
Windows x86-64 web-based installer (64 ビット Python、推奨) またはx86 executable (32 ビット Python) インストーラーのいずれかを選択します。
コマンドpython --version使用して動作していることを確認します。
python -m pip install nuitka
コマンドpython -m nuitka --versionを使用して確認します。
mkdir HelloWorld
hello.pyという名前のPythonファイルを作成します。
def talk(message):return "Talk " + messagedef main():print(talk("Hello World"))if __name__ == "__main__":main()いつもどおりにしてください。正しく動作しないコードで Nuitka を実行することは、デバッグが容易ではありません。
Python hello.py
python -m nuitka hello.py
注記
これにより、適切な MSVC がインストールされていない限り、C キャッシュ ツール (生成された C コードの繰り返しコンパイルを高速化するため) と MinGW64 ベースの C コンパイラをダウンロードするよう求められます。これらの質問の両方にyesと答えてください。
hello.py近くに作成されたhello.exeを実行します。
配布するには、 --standaloneオプションを使用してビルドします。これにより、単一の実行可能ファイルではなくフォルダー全体が出力されます。作成されたhello.distフォルダーを他のマシンにコピーして実行します。
単一のファイルを作成する--onefile試すこともできますが、データ ファイルが見つからない場合など、デバッグが難しくなるだけなので、使用する前に単なるスタンドアロンが動作していることを確認してください。
メインプログラムである単一のファイルだけでなく、プログラム全体を再帰的にコンパイルしたい場合は、次のように実行します。
python -m nuitka --follow-importsプログラム.py
注記
--follow-importsよりもさらに細かいコントロールが利用可能です。 nuitka --helpの出力を考えてみましょう。コンパイルに含めるモジュールの数を減らし、代わりに通常の Python を使用すると、コンパイルが速くなります。
動的にロードされるファイルを含むソース ディレクトリがある場合、つまり、 PYTHONPATH経由で通常のインポート ステートメントの後に再帰しても見つからないファイルがある場合 (これが推奨される方法です)、指定されたディレクトリが実行可能：
python -m nuitka --follow-imports --include-plugin-directory=plugin_dirプログラム.py
注記
動的インポートを行わない場合は、コンパイル時にPYTHONPATH設定するだけです。
--include-plugin-directory Nuitka が予測できず、ディレクトリからの__import__()呼び出しを行う場合にのみ使用してください。Python インストールからのすべてについては、 --include-moduleまたは--include-package使用してください。
注記
結果のファイル名は、Windows ではprogram.exe 、他のプラットフォームではprogram.binになりますが、 --output-filename使用すると変更できます。
注記
結果として得られるバイナリは、引き続き CPython と、インストールされている C 拡張モジュールに依存します。
別のマシンにコピーできるようにしたい場合は、 --standaloneを使用して、作成されたprogram.distディレクトリをコピーし、その中に置かれたprogram.exe (Windows)またはprogram (他のプラットフォーム)を実行します。
単一の拡張モジュールをコンパイルしたい場合は、次のことだけを行う必要があります。
python -m nuitka --module some_module.py
結果のファイルsome_module.soは、 some_module.pyの代わりに使用できます。
重要
Python はエントリ ポイントとしてモジュール名派生関数を要求するため、生成された拡張モジュールのファイル名は変更してはなりません。この場合はPyInit_some_moduleであり、ファイルの名前を変更してもそれは変わりません。ソース コードのファイル名をバイナリ名と一致させます。
注記
拡張モジュールとそのソース コードの両方が同じディレクトリにある場合、拡張モジュールがロードされます。ソース コードへの変更は、再コンパイルした場合にのみ有効になります。
注記
オプション--follow-import-to同様に機能しますが、含まれているモジュールはsome_module名をインポートした後でのみインポート可能になります。この種のインポートが Nuitka に表示されない場合 (動的に作成された場合など)、その場合は--include-moduleまたは--include-package使用できますが、静的インポートの場合は必要ありません。
注記
拡張モジュールに他の拡張モジュールを含めることはできません。これを可能にするにはホイールを作成する必要があります。
注記
結果として得られる拡張モジュールは、同じバージョンの CPython にのみロードでき、他の拡張モジュールは含まれません。
パッケージ全体をコンパイルしてすべてのモジュールを埋め込む必要がある場合は、それも可能ですが、次のように Nuitka を使用します。
python -m nuitka --module some_package --include-package=some_package
注記
パッケージの内容を含めるには、手動で指定する必要があります。それ以外の場合、パッケージはほとんど空です。必要に応じて、より具体的に指定して、その一部のみを含めたり、その一部を除外したりすることができます。たとえば、 --nofollow-import-to='*.tests'使用すると、コードの未使用のテスト部分は含められません。
注記
パッケージ内にあるデータ ファイルはこのプロセスでは埋め込まれないため、この方法では自分でデータ ファイルをコピーする必要があります。あるいは、Nuitka コマーシャルのファイル埋め込みを使用することもできます。
他のシステムへの配布には、 --standalone指定できるフォルダーを作成するスタンドアロン モードがあります。
python -m nuitka --スタンドアロンプログラム.py
このモードでは、すべてのインポートに従うことがデフォルトです。具体的に--nofollow-import-toと指定することでモジュールを選択的に除外できますが、プログラムの実行時にインポートしようとするとImportErrorが発生します。これにより動作が異なる可能性がありますが、賢く実行すればコンパイル時間も短縮される可能性があります。
データ ファイルを含めるには、オプション--include-data-files=<source>=<target>を使用します。ソースはファイル システム パスですが、ターゲットは相対的に指定する必要があります。スタンドアロン モードの場合は手動でコピーすることもできますが、これにより追加のチェックが行われる可能性があり、onefile モードの場合は手動でコピーすることはできません。
ディレクトリ内の一部またはすべてのファイルをコピーするには、オプション--include-data-files=/etc/*.txt=etc/を使用します。ここで、ファイルのシェル パターンと、ファイルを配置するサブディレクトリを指定できます。末尾のスラッシュで区切ります。
重要
Nuitka はデータ ファイルのコードを考慮せず、DLL や Python ファイルをデータ ファイルとして含めません。また、それらが機能することを期待していますが、実際に何をしているのかを理解していない限り、実際には機能しません。
以下では、非コード データ ファイルとは、これらの基準のいずれにも一致しないすべてのファイルを指します。
| サフィックス | 理論的根拠 | 解決 |
|---|---|---|
.py | Nuitka は、含められる stdlib モジュールもトリミングします。 Python コードが認識されない場合、依存関係は分析されず、その結果、機能しません。 | 代わりに--include-module使用してください |
.pyc | .pyと同じ。 | 代わりに、ソース コードから--include-module使用してください。 |
.pyo | .pycと同じ。 | 代わりに、ソース コードから--include-module使用してください。 |
.pyw | .pyと同じ。 | 複数のプログラムを含める場合は、代わりに複数の--main引数を使用します。 |
.pyi | これらはコードに似ており、実行時には必要ないため、無視されます。実際にそれらに依存するlazyパッケージについては、その必要性を排除するコンパイル時ソリューションを作成しました。 | サード パート ソフトウェアが必要な場合は問題を提起します。 |
.pyx | これらは実行時に使用されない Cython ソース コードであるため無視されます。 | |
.dll | これらは通常はデータ ファイルではないため、無視されます。サードパーティのパッケージが実際にデータとして使用する場合 ( .NETパッケージなど)、そのパッケージ構成でそれを解決します。 | これらの Nuitka パッケージ構成と、それらを使用するパッケージのdllセクションを作成します。まれに、特別な構成を備えたデータ ファイル セクションが適切な場合もあります。 |
.dylib | これらは macOS 拡張モジュールまたは DLL であるため、無視されます。 | dllセクションの構成を追加するか、不足しているdependsを追加する必要があります |
.so | これらは Linux、BSD などの拡張モジュールまたは DLL であるため、無視されます。 | dllセクションの構成を追加するか、不足しているdependsを追加する必要があります |
.exe | これらは Windows のバイナリです。 | Nuitka パッケージ設定を追加して、それらを DLL として含め、 executable: yes |
.bin | これらは Windows 以外のバイナリであり、それ以外は.exeと同じです。 |
また、フォルダーも無視されます。これらはsite-packages 、 dist-packages 、 vendor-packagesであり、そうでなければ完全な virtualenv が含まれることになりますが、これは決して良いことではありません。また、 __pycache__フォルダーも常に無視されます。 MacOS 以外では、ファイル.DS_Storeも無視され、 py.typedフォルダーは IDE にとってのみ意味を持ち、 .pyiファイルと同様に無視されます。
コード以外のファイルをすべて含むフォルダー全体をコピーするには、 --include-data-dir=/path/to/images=images使用して、それらのファイルを宛先に配置します。また、 --noinclude-data-filesを使用したい場合は、 --noinclude-data-filesオプションを使用してそれらを削除します。コード ファイルは、上記で詳しく説明した DLL、実行可能ファイル、Python ファイルなどであり、無視されます。これらについては、 --include-data-files=/binaries/*.exe=binary/フォームを使用して強制することができますが、これはお勧めできず、実行時に問題が発生することが知られています。
パッケージ データの場合は、 --include-package-data使用する、より良い方法があります。これは、パッケージのすべての非コード データ ファイルを自動的に検出し、コピーします。シェルスタイルのパターンも受け入れます。これにより、パッケージ ディレクトリを自分で見つける必要がなくなるため、利用可能な場合は常に使用することをお勧めします。機能的には--include-data-dirと非常に似ていますが、正しいフォルダーを見つけられるという利点があります。
データ ファイルに関しては、ほとんどの場合、自分で行う必要があります。 Nuitka は人気のあるパッケージで必要なものを追跡していますが、不完全である可能性があります。これらの中で何かが見つかった場合は、問題を提起してください。さらに良いことに、Nuitka パッケージ構成を強化して PR を上げます。私たちは、サードパーティ製ソフトウェアが箱から出してすぐに動作することを望んでいます。
それが機能している場合は、必要に応じて onefile モードを使用できます。
python -m nuitka --onefile Program.py
これにより、プログラムを実行する前に、ターゲット上でそれ自体を抽出する単一のバイナリが作成されます。ただし、プログラムに関連するファイルへのアクセスが影響を受けることに注意してください。「Onefile: ファイルの検索」セクションも必ずお読みください。
# 一時フォルダーに解凍するバイナリを作成しますpython -m nuitka --onefile project.py
注記
アイコン、スプラッシュ画面、バージョン情報など、プラットフォーム固有のオプションが他にもあります。これらの詳細については--help出力を検討し、「調整」セクションを確認してください。
解凍には、デフォルトで一意のユーザー一時パスが使用され、その後削除されますが、このデフォルトの--onefile-tempdir-spec="{TEMP}/onefile_{PID}_{TIME}"はパスで上書きできます。仕様を指定し、キャッシュされたパスを使用して、繰り返しの解凍を回避します。たとえば、バージョンを使用する--onefile-tempdir-spec="{CACHE_DIR}/{COMPANY}/{PRODUCT}/{VERSION}"を使用します。情報、およびユーザー固有のキャッシュ ディレクトリ。
注記
キャッシュされたパスの使用は、たとえば Windows ファイアウォールが機能する場合に関連します。そうしないと、バイナリが実行されるたびに異なるものになってしまうからです。
現在、次の拡張トークンが利用可能です。
| トークン | これが何を拡張するのか | 例 |
|---|---|---|
| {温度} | ユーザー一時ファイルディレクトリ | C:Users...AppDataLocalsTemp |
| {PID} | プロセスID | 2772 |
| {時間} | エポックからの秒数。 | 1299852985 |
| {プログラム} | 実行可能ファイルの完全なプログラム実行時ファイル名。 | C:SomeWhereYourOnefile.exe |
| {PROGRAM_BASE} | 実行可能ファイルのランタイムファイル名のサフィックスはありません。 | C:SomeWhereYourOnefile |
| {CACHE_DIR} | ユーザーのキャッシュ ディレクトリ。 | C:UsersSomeBodyAppDataLocal |
| {会社} | --company-nameとして指定される値 | あなたの会社名 |
| {製品} | --product-nameとして指定される値 | あなたの製品名 |
| {バージョン} | --file-versionと--product-versionの組み合わせ | 3.0.0.0-1.0.0.0 |
| {家} | ユーザーのホームディレクトリ。 | /家/誰か |
| {なし} | ファイル出力に指定する場合は、 Noneが使用されます。 | 以下の通知を参照してください |
| {NULL} | ファイル出力に提供される場合、 os.devnullが使用されます | 以下の通知を参照してください |
重要
指定したパスを一意にするのはユーザーの責任です。Windows では実行中のプログラムがロックされます。固定フォルダー名を使用することは可能ですが、その場合、プログラムが再起動されてロックの問題が発生する可能性があります。
通常、パスを一意にするには、 {TIME}または少なくとも{PID}を使用する必要があります。これは主に、たとえば、選択した場所に物を置いたり、命名規則に従ったりするようなユースケースを目的としています。
重要
--force-stdout-specと--force-stderr-specを使用して出力と標準エラー出力を無効にする場合、値{NONE}と{NULL}を使用するとそれが実現されますが、効果は異なります。 {NONE}を指定すると、対応するハンドルはNoneになります。その結果、たとえばsys.stdout Noneになります。これは、 os.devnullを指すファイルによってバックアップされる、つまり書き込みができる{NULL}とは異なります。
{NONE}を使用すると、実際に使用された場合にRuntimeError: lost sys.stdout発生する可能性があります。 {NULL}ではそんなことは起こりません。ただし、一部のライブラリはこれをログ メカニズムの入力として処理し、Windows ではこれにより、 {NONE}のように動作するpythonw.exeとの互換性が保たれます。
setup.py 、 setup.cfg 、またはpyproject.tomlを使用してソフトウェア用のホイールを作成している場合、Nuitka を使用するのは非常に簡単です。
最も一般的なsetuptoolsアプローチから始めましょう。もちろん、Nuitka がインストールされていれば、 bdist_wheelではなくターゲットのbdist_nuitka単純に実行できます。すべてのオプションを取得し、Nuitka に固有のさらにいくつかのオプションを指定できます。
# 他のビルドシステムを使用しない場合の setup.py の場合:setup( # データ ファイルは Nuitka ではなく setuptools によって処理されます
package_data={"some_package": ["some_file.txt"]},
..., # これは、Nuitka オプションを渡すためのものです。
command_options={ 'nuitka': { # ブール型オプション、たとえば C コンパイル コマンドを使用する場合 '--show-scons': True、# 値のないオプション、たとえば Clang の使用を強制する '--clang': None、# オプションあり単一の値、例: Nuitka のプラグインを有効にする '--enable-plugin': "pyside2"、# 複数の値を持つオプション、例: モジュールを含めない'--nofollow-import-to' : ["*.tests", "*.distutils"],
}、
}、
)# 他のビルド システムでの setup.py の場合:# 引数のタプルの性質は、# 完全な互換性を主張する「setuptools」とそのプラグインの暗い性質によって必要とされます。# 例: "setuptools_rust"setup( # データ ファイルNuitka ではなく setuptools によって処理されます。
package_data={"some_package": ["some_file.txt"]},
..., # これは、Nuitka オプションを渡すためのものです。
..., command_options={ 'nuitka': { # ブール型オプション、たとえば C コンパイル コマンドを扱う場合 '--show-scons': ("setup.py", True)、 # 値のないオプション、たとえば強制的に使用するClang '--clang': ("setup.py", None)、 # 単一の値を持つオプション、たとえば Nuitka のプラグインを有効にする '--enable-plugin': ("setup.py", "pyside2"), # 複数の値を持つオプション。例: モジュール '--nofollow-import-to' を含めないようにします: ("setup.py", ["*.tests", "*.distutils "])、
}
}、
）何らかの理由でターゲットを変更できない、または変更したくない場合は、これをsetup.pyに追加できます。
# setup.pysetup( ...、build_with_nuitka=True)
注記
コンパイルを一時的に無効にするには、上記の行を削除するか、値をFalseに編集するか、必要に応じて環境変数から値を取得します (例: bool(os.getenv("USE_NUITKA", "True")) 。これはあなた次第です。
または、 setup.cfgに置くこともできます
[メタデータ]build_with_nuitka = true
そして最後に重要なことですが、Nuitka は新しいbuildメタもサポートしているため、すでにpyproject.tomlがある場合は、この値を単純に置き換えるか追加します。
[build-system]requires = ["setuptools>=42", "wheel", "nuitka", "toml"]build-backend = "nuitka.distutils.Build"# データ ファイルは Nuitka ではなく setuptools によって処理されます。 [tool.setuptools.package-data]some_package = ['data_file.txt'] [tool.nuitka]# これらは推奨されませんが、効果があることは明らかです。# ブール型オプション。たとえば、C コンパイル コマンドを使用する場合は、先頭の# ダッシュは省略されますshow-scons = true# 単一の値を持つオプション。たとえば、enable Nuitkaenable-plugin = "pyside2"# のプラグイン。複数の値を持つオプション。たとえば、モジュールの組み込みを回避し、# リスト引数を受け入れます。nofollow-import-to = ["*.tests", "*.distutils"]
注記
C:Users...Nuitkaのような絶対パスを超えるnuitka要件については、Linux でも動作します。先頭に2 つのスラッシュを付けた絶対パスを使用します (例: //home/.../Nuitka )。
注記
どのようなアプローチを採用しても、これらのホイール内のデータ ファイルは Nuitka ではまったく処理されず、setuptools によって処理されます。ただし、Nuitka コマーシャルのデータ ファイル埋め込みを使用することはできます。その場合、実際には、ホイール内のファイルとしてではなく、拡張モジュール自体の中にファイルを埋め込むことになります。
複数のプログラムがあり、それぞれを実行可能にする必要がある場合、以前は複数回コンパイルして、それらすべてをデプロイする必要がありました。スタンドアロン モードでは、フォルダーの共有は可能ですが、Nuitka では実際にはサポートされていなかったため、これはもちろんかなり無駄であることを意味します。
Multidistを入力します。指定された位置引数を置換または追加するオプション--mainがあります。そしてそれは複数回与えることができます。複数回指定すると、Nuitka は指定されたすべてのプログラムのコードを含むバイナリを作成しますが、プログラム内で使用されるモジュールは共有されます。したがって、複数回配布する必要はありません。
メインパスのベース名とエントリポイントを呼び出しましょう。もちろん、これらの名前は異なる必要があります。その後、作成されたバイナリはいずれかのエントリ ポイントを実行でき、 sys.argv[0]が表示されるものに反応します。したがって、正しい方法で実行するか ( subprocessや OS API などを使用してこの名前を制御できます)、バイナリの名前を変更するかコピーするか、バイナリにシンボリックリンクすることによって、奇跡を達成することができます。
これにより、非常に異なるプログラムを 1 つに結合することができます。
注記
この機能はまだ実験段階です。慎重に使用し、望ましくない動作に遭遇した場合は発見結果を報告してください。
このモードは、スタンドアロン、onefile、および単なるアクセラレーションで動作します。モジュールモードでは動作しません。
GitHub ワークフローとの統合には、統合を非常に簡単にするこの Nuitka-Action を使用する必要があります。ただし、ローカル コンパイルから始める必要がありますが、Nuitka を使用したクロスプラットフォーム コンパイルではこれが最も簡単です。
これは 3 つすべての OS 上に構築されるワークフローの例です。
ジョブ:ビルド: 戦略: マトリックス: os: [macos-最新、ubuntu-最新、Windows-最新]
実行中: ${{ マトリックス.os }}
手順:
- 名前: チェックアウト リポジトリの使用:actions/checkout@v4 - 名前: セットアップ Python の使用:actions/setup-python@v5 使用条件: Python バージョン: '3.10' キャッシュ: 'pip' キャッシュ依存関係パス: | **/requirements*.txt - 名前: 依存関係をインストールします。実行: | pip install -rrequirements.txt -rrequirements-dev.txt - name: Nuitka を使用したビルド実行可能ファイル: Nuitka/Nuitka-Action@main with: nuitka-version: main script-name: your_main_program.py # さらに多くの Nuitka オプションが利用可能、アクションドキュメントを参照してください。ただし、コード内で nuitka-project: オプションを使用するのが最善です。そのため、たとえば、macOS と、そこでアプリバンドルを作成します。 onefile: true - 名前: アップロード アーティファクトの使用: action/upload-artifact@v3 使用: 名前: ${{runner.os }} ビルド パス: | # 3 つの OS 用に作成されたものと一致します build/*.exe build/*.bin build/*.app/**/*アプリが GUI の場合、たとえばyour_main_program.pyには、コード内の Nuitka オプションで説明されているように、これらのコメントが含まれている必要があります。これは、macOS ではこれがバンドルである必要があるためです。
# コンパイル モード、どこでもスタンドアロン (macOS を除く) アプリ バンドル# nuitka-project-if: {OS} in ("Windows", "Linux", "FreeBSD"):# nuitka-project: --onefile# nuitka-project -if: {OS} == "Darwin":# nuitka-project: --standalone# nuitka-project: --macos-create-app-bundle#見栄えを良くするために、アイコンを指定できます。 Windows では、アイコン ファイル、テンプレート実行可能ファイル、または PNG ファイルを提供できます。これらはすべて機能し、組み合わせることもできます。
# これらは Windows 上にアイコンを含むバイナリを作成しますpython -m nuitka --onefile --windows-icon-from-ico=your-icon.png project.py python -m nuitka --onefile --windows-icon-from-ico=your-icon.ico プログラム.py python -m nuitka --onefile --windows-icon-template-exe=your-icon.ico Program.py# これらは macOS 上にアイコンを含むアプリケーション バンドルを作成しますpython -m nuitka --macos-create-app-bundle --macos- app-icon=your-icon.png プログラム.py python -m nuitka --macos-create-app-bundle --macos-app-icon=your-icon.icns Program.py
注記
Nuitka を使用すると、プラットフォーム固有のアイコンを作成する必要はありませんが、代わりに、ビルド中に PNG だけでなく他の形式もその場で変換します。
macOS アプリケーション バンドルの資格は、オプション--macos-app-protected-resourceを使用して追加できます。すべての値は Apple のこのページにリストされています。
値の例は、マイクへのアクセスを要求する場合の--macos-app-protected-resource=NSMicrophoneUsageDescription:Microphone accessです。コロンの後には説明文が入ります。
注記
説明部分でスペースを使用する可能性が高い場合、シェルが Nuitka に到達し、Nuitka の引数として解釈されないようにするために、スペースを引用符で囲む必要があることに注意してください。
Windows では、ユーザーが指示しない限り、プログラムによってコンソールが開かれることはありません。 Nuitka はデフォルトでそれを表示しませんが、 --console=force使用して強制的に表示することができます。そうすれば、プログラムは実行時に新しいターミナル ウィンドウを開きます。
スプラッシュ スクリーンは、プログラムの起動が遅い場合に役立ちます。 Onefile の起動自体は遅くありませんが、プログラムが遅くなる可能性があり、使用するコンピューターの速度が実際にどのくらいになるかは実際にはわかりません。そのため、Onefile を用意しておくとよいでしょう。幸いなことに、Nuitka を使用すると、Windows に簡単に追加できます。
スプラッシュ スクリーンの場合は、それを PNG ファイルとして指定する必要があります。その後、プログラムの準備が完了したら (インポートが完了し、ウィンドウを準備し、データベースに接続し、スプラッシュ スクリーンが必要になったときなど) 必ずスプラッシュ スクリーンを無効にしてください。去っていく。ここでは、プロジェクト構文を使用してコードを作成と結合し、これをコンパイルします。
# nuitka-project: --onefile# nuitka-project: --onefile-windows-splash-screen-image={MAIN_DIRECTORY}/Splash-Screen.png# これが何であれ、明らかにprint("起動を10秒遅らせています..." )import time, tempfile, ostime.sleep(10)# このコードを使用して、スプラッシュ スクリーンの削除を通知します。 os.environ の「NUITKA_ONEFILE_PARENT」:splash_filename = os.path.join( tempfile.gettempdir(), "onefile_%d_splash_フィードバック.tmp" % int(os.environ["NUITKA_ONEFILE_PARENT"]),
) if os.path.exists(splash_filename): os.unlink(splash_filename)print("完了...スプラッシュは消えているはずです。")
...# プログラムの残りの部分はここにあります。プログラムと Nuitka パッケージ化の分析のために、コンパイル レポートが利用可能です。 Nuitka に組み込まれたテンプレートをいくつか用意して、カスタム レポートを作成することもできます。これらのレポートには、すべての詳細情報が含まれます。たとえば、モジュールのインポートが試みられたが見つからなかったとき、それがどこで発生したかを確認できます。バグ報告については、レポートを提出することを強くお勧めします。
著作権や商標情報、会社名、製品名などを編集物に添付できます。これは、Windows では作成されたバイナリ、または macOS ではアプリケーション バンドルのバージョン情報に使用されます。不足しているものがございましたら、お知らせください。
デフォルトでは、Nuitka は--deploymentなしでコンパイルされます。これにより、Nuitka の誤った使用をデバッグすることを目的とした一連の安全装置とヘルパーがオンのままになります。
これは新機能であり、ここで文書化されている一連の保護とヘルパーを実装します。
したがって、コンパイル後、 sys.executableコンパイルされたバイナリになります。 multiprocessing 、 joblib 、またはlokyなどの-c commandの場合、これらが通常行うことは、 sys.executableを使用してフルpythonから実行する-m module_nameを期待することです。サービスデーモンとして一時的または永続的に他のコードを起動します。
しかし、nuitkaを使用すると、これはプログラムを再度実行し、これらの議論をsys.argvに置きます。これは、CPUカウントプロセスを生成するCPUカウントプロセスを生成することになります。
それが、これがデフォルトのnuitkaで起こる理由です。
./hello.dist/hello.bin -l fool -m foom -n foon -o fooo -p エラー、プログラムは「-M」引数で自分自身を呼び出そうとしました。 '-no-deployment-flag = selfexecution」で無効にします。
あなたのプログラムは、独自のコマンドラインの解析を持っている可能性があり、再実行を試みるサポートされていないパッケージを使用しない場合があります。この場合、コンパイル時に使用する必要があります--no-deployment-flag=self-execution必要です。
一部のパッケージは、輸入の故障の理由が何であるかについての役立つ情報だと思うものを出力します。コンパイルされたプログラムを使用すると、非常に間違っていることが非常にあります。非展開モードでそれらを修復しようとします。以下は、 imageioプラグインを機能させるコマンドをユーザーに示すために、PIPインストール（これは問題ではない）を求めるメッセージを変更する例を示します。
-odule-name： 'imageio.core.imopen'
抗bloat：
-datrements_plain： '`pip install imageio [{config.install_name}]`インストールする'： '` - include-module = {config.module_name}` runtimeerror 'when：' not Deployment '展開モードは比較的新しいものであり、常に追加の機能が追加されています。たとえば、 FileNotFoundErrorの何かが近日中に来るはずです。
もちろん、これらすべてのヘルパーは、 --deploymentで一度に無効にすることができますが、デバッグのためには、それを再度に戻すことをお勧めします。 Nuitka Projectオプションと環境変数を使用して、この条件付きを使用することをお勧めします。
それらをすべて無効にする必要がありますか？
無効化は選択的にのみ発生する必要がありますが、PYPIのアップグレード、コードの変更により、これらの問題はすべて潜入できます。展開モードのスペース節約は現在無視できます。あなたがそれがあなたに影響を与えることができないことを知っているなら、またはそれがそうであれば、あなたはそれを必要としません。将来のもののいくつかは、明らかに初心者レベルの使用で準備されます。
nuitkaのデフォルト設定を備えたWindowsにコンパイルされたバイナリと、一部のAVベンダーがマルウェアとして認識される可能性があります。これは回避可能ですが、Nuitkaのコマーシャルでのみ、それを行う方法についての実際のサポートと指示があり、これを典型的なコマーシャルの必要性のみと見なしています。 https://nuitka.net/doc/commercial.html
Linuxスタンドアロンの場合、他のLinuxバージョンで動作するバイナリを構築することは非常に困難です。これは主に、Linuxでは、多くのソフトウェアがコンクリートDLLを特別にターゲットにして構築されているためです。 GLIBCのようなものは、ビルドビルドにエンコードされ、1つの重要な例を挙げるためだけに、古いGlibcで実行されません。
解決策は、サポートされている最古のOSに基づいて構築することです。それを選んでセットアップするのは退屈かもしれないので、ログインすることができ、それを維持することができます
