Nuitka
1.0.0
Ce document est la première lecture recommandée lorsque vous commencez à utiliser Nuitka . Sur cette page, vous en apprendrez plus sur les principes fondamentaux de Nuitka , tels que le type de licence, les cas d'utilisation, les exigences et les crédits.
Table des matières
Exigences
Usage
Configuration du didacticiel et build sous Windows
Cas d'utilisation
Ajustements
Problèmes typiques
Conseils
Rapport de compilation
Performance
Fonctionnalité non prise en charge
Nuitka est le compilateur Python. Il est écrit en Python. Il s'agit d'un remplacement ou d'une extension transparente de l'interpréteur Python et compile toutes les constructions de Python 2 (2.6, 2.7) et Python 3 (3.4 - 3.13), lorsqu'elles sont elles-mêmes exécutées avec cette version de Python.
Il exécute ensuite le code non compilé et le code compilé ensemble de manière extrêmement compatible.
Vous pouvez utiliser librement tous les modules de la bibliothèque Python et tous les modules d’extension.
Nuitka traduit les modules Python en un programme de niveau C qui utilise ensuite libpython et ses propres fichiers C statiques pour s'exécuter de la même manière que CPython.
Toute optimisation vise à éviter les frais généraux là où ils sont inutiles. Aucun n'est destiné à supprimer la compatibilité, bien que de légères améliorations soient occasionnellement apportées, où tous les bogues du Python standard ne sont pas émulés, par exemple des messages d'erreur plus complets sont donnés, mais il existe un mode de compatibilité complète pour désactiver même cela.
Pour garantir le bon fonctionnement de Nuitka , assurez-vous de respecter la configuration système requise, qui inclut les composants suivants :
Compilateur C
Python
Système opérateur
Architecture
Vous avez besoin d'un compilateur C prenant en charge C11 ou bien d'un compilateur C++ pour C++03 [1].
Actuellement, cela signifie que vous devez utiliser l'un de ces compilateurs :
Le compilateur MinGW64 C11, sous Windows, doit être basé sur gcc 11.2 ou supérieur. Il sera automatiquement téléchargé si aucun compilateur C utilisable n'est trouvé, ce qui est la méthode recommandée pour l'installer, car Nuitka le mettra également à niveau pour vous.
Visual Studio 2022 ou supérieur sous Windows [2]. Pack de langue anglais pour de meilleurs résultats (Nuitka filtre les sorties inutiles, mais uniquement pour la langue anglaise). Il sera utilisé par défaut s'il est installé.
Sur toutes les autres plateformes, le compilateur gcc d'au moins la version 5.1, et en dessous le compilateur g++ d'au moins la version 4.4 comme alternative.
Le compilateur clang sur macOS X et la plupart des architectures FreeBSD.
Sous Windows, le compilateur clang-cl sous Windows peut être utilisé s'il est fourni par le programme d'installation de Visual Studio.
| [1] | La prise en charge de ce C11 est assurée avec gcc 5.x ou supérieur ou toute version de clang. Les anciens compilateurs MSVC ne le font pas encore. Mais comme solution de contournement, avec Python 3.10 ou version antérieure, le standard de langage C++03 chevauche considérablement le C11, il est alors utilisé à la place. |
| [2] | Téléchargez gratuitement depuis https://www.visualstudio.com/en-us/downloads/download-visual-studio-vs.aspx (les éditions communautaires fonctionnent très bien). La dernière version est recommandée, mais pas obligatoire. D'un autre côté, il n'est pas nécessaire de prendre en charge les versions antérieures à Windows 10, et elles peuvent fonctionner pour vous, mais la prise en charge de ces configurations n'est disponible que pour les utilisateurs commerciaux. |
Python 2 (2.6, 2.7) et Python 3 (3.4 — 3.13) sont pris en charge. Si à tout moment il existe une version stable de Python qui ne figure pas dans cette liste, soyez assuré qu'elle est en cours de développement et qu'elle sera ajoutée.
Important
Pour Python 3.4 et uniquement cette version, nous avons besoin d'une autre version de Python comme dépendance au moment de la compilation .
Nuitka lui-même est entièrement compatible avec toutes les versions répertoriées, mais Scons en tant qu'outil utilisé en interne ne l'est pas.
Pour ces versions, vous devez également installer Python2 ou Python 3.5 ou supérieur, mais uniquement pendant la compilation. C'est à utiliser avec Scons (qui orchestre la compilation C), qui ne prend pas en charge les mêmes versions Python que Nuitka.
De plus, sous Windows, Python2 ne peut pas être utilisé car clcache ne fonctionne pas avec, il faut y installer Python 3.5 ou supérieur.
Nuitka trouve ces versions Python nécessaires (par exemple sur Windows via le registre) et vous ne devriez pas le remarquer tant qu'elles sont installées.
De plus en plus, d'autres fonctionnalités sont disponibles lorsqu'un autre Python a installé un certain package. Par exemple, la compression onefile fonctionnera pour un Python 2.x lorsqu'un autre Python sur lequel le package zstandard est installé est trouvé.
Déplacer les binaires vers d'autres machines
Les binaires créés peuvent être rendus exécutables indépendamment de l'installation de Python, avec les options --standalone et --onefile .
Suffixe du nom de fichier binaire
Les binaires créés ont un suffixe .exe sous Windows. Sur d'autres plates-formes, ils n'ont pas de suffixe pour le mode autonome, ni de suffixe .bin , que vous êtes libre de supprimer ou de modifier, ou de spécifier avec l'option -o .
Le suffixe pour le mode d'accélération est ajouté juste pour être sûr que le nom du script d'origine et le nom du binaire n'entrent jamais en collision, afin que nous puissions écraser le binaire en toute sécurité sans détruire le fichier source d'origine.
Il doit s'agir de CPython, Anaconda Python ou Homebrew
Vous avez besoin de l'implémentation Python standard, appelée "CPython", pour exécuter Nuitka car elle est étroitement liée aux détails de son implémentation.
Cela ne peut pas provenir de la boutique d'applications Windows
On sait que le magasin d'applications Windows Python ne fonctionne définitivement pas, c'est vérifié.
Ce ne peut pas être pyenv sur macOS
On sait que macOS "pyenv" ne fonctionne pas . Utilisez plutôt Homebrew pour les installations Python auto-compilées. Mais notez que le mode autonome sera pire sur ces plates-formes et ne sera pas aussi rétrocompatible avec les anciennes versions de macOS.
Systèmes d'exploitation pris en charge : Linux, FreeBSD, NetBSD, macOS et Windows (32 bits/64 bits/ARM).
D'autres fonctionneront également. La portabilité devrait être généralement bonne, mais par exemple, l'utilisation interne des Scons de Nuitka devra peut-être être adaptée ou nécessiter le passage de drapeaux. Assurez-vous de faire correspondre l'architecture du compilateur Python et C, sinon vous recevrez des messages d'erreur énigmatiques.
Les architectures prises en charge sont x86, x86_64 (amd64) et arm, probablement bien d'autres.
D'autres architectures devraient également fonctionner, prêtes à l'emploi, car Nuitka n'utilise généralement aucune spécificité matérielle. Ce ne sont que ceux testés et connus pour être bons. Les commentaires sont les bienvenus. En général, les architectures prises en charge par Debian peuvent également être considérées comme bonnes et testées.
La méthode recommandée pour exécuter Nuitka est <the_right_python> -m nuitka pour être absolument certain de l'interpréteur Python que vous utilisez, il est donc plus facile de faire correspondre ce que Nuitka a.
La meilleure façon d'exécuter Nuitka nue est à partir d'une extraction de source ou d'une archive, sans changement de variable d'environnement, le plus remarquable est que vous n'avez pas du tout à jouer avec PYTHONPATH pour Nuitka. Vous exécutez simplement les scripts nuitka et nuitka-run directement sans aucune modification de l'environnement. Vous souhaiterez peut-être ajouter le répertoire bin à votre PATH pour votre commodité, mais cette étape est facultative.
De plus, si vous souhaitez exécuter avec le bon interpréteur, dans ce cas, assurez-vous d'exécuter <the_right_python> bin/nuitka et soyez bon.
Choisissez le bon interprète
Si vous rencontrez une SyntaxError vous avez très certainement choisi le mauvais interprète pour le programme que vous compilez.
Nuitka a une option --help pour afficher ce qu'elle peut faire :
nuitka --aide
La commande nuitka-run est la même que nuitka , mais avec une valeur par défaut différente. Il essaie de compiler et d'exécuter directement un script Python :
nuitka-run --help
Cette option différente est --run et transmet les arguments après la première non-option au binaire créé, elle est donc un peu plus similaire à ce que fera python simple.
Pour la plupart des systèmes, il y aura des packages sur la page de téléchargement de Nuitka. Mais vous pouvez également l'installer à partir du code source comme décrit ci-dessus, mais comme tout autre programme Python, il peut être installé via la routine python setup.py install .
Avis pour l'intégration avec les workflows GitHub, il y a ce Nuitka-Action que vous devez utiliser et qui le rend vraiment facile à intégrer. Vous devriez cependant commencer par une compilation locale, mais ce sera plus simple pour une compilation multiplateforme avec Nuitka.
Nuitka est sous licence Apache, version 2.0 ; vous ne pouvez pas l'utiliser sauf en conformité avec la Licence.
Vous pouvez obtenir une copie de la licence sur http://www.apache.org/licenses/LICENSE-2.0
Sauf disposition contraire de la loi applicable ou accord écrit, le logiciel distribué sous la licence est distribué « TEL QUEL », SANS GARANTIE OU CONDITION D'AUCUNE SORTE, expresse ou implicite. Consultez la licence pour connaître la langue spécifique régissant les autorisations et les limitations en vertu de la licence.
Il s’agit d’étapes de base si vous n’avez rien installé, bien sûr, si vous avez l’une des pièces, ignorez-la.
Téléchargez et installez Python depuis https://www.python.org/downloads/windows
Sélectionnez l’un des Windows x86-64 web-based installer (Python 64 bits, recommandé) ou un programme d’installation x86 executable (Python 32 bits).
Vérifiez qu'il fonctionne à l'aide de la commande python --version .
python -m pip install nuitka
Vérifiez à l'aide de la commande python -m nuitka --version
mkdir BonjourMonde
créer un fichier python nommé hello.py
def talk(message):return "Talk " + messagedef main():print(talk("Hello World"))if __name__ == "__main__":main()Faites comme vous le feriez normalement. Exécuter Nuitka sur du code qui ne fonctionne pas correctement n'est pas plus facile à déboguer.
python bonjour.py
python -m nuitka bonjour.py
Note
Cela vous invitera à télécharger un outil de mise en cache C (pour accélérer la compilation répétée du code C généré) et un compilateur C basé sur MinGW64, sauf si un MSVC approprié est installé. Dites yes à ces deux questions.
Exécutez le hello.exe créé près de hello.py .
Pour distribuer, construisez avec l'option --standalone , qui ne produira pas un seul exécutable, mais un dossier entier. Copiez le dossier hello.dist résultant sur l'autre machine et exécutez-le.
Vous pouvez également essayer --onefile qui crée un seul fichier, mais assurez-vous que le simple fichier autonome fonctionne avant de vous y tourner, car cela rendra le débogage encore plus difficile, par exemple en cas de fichiers de données manquants.
Si vous souhaitez compiler un programme entier de manière récursive, et pas seulement le fichier unique qui constitue le programme principal, procédez comme ceci :
python -m nuitka --follow-imports programme.py
Note
Il existe des contrôles plus fins que --follow-imports disponibles. Considérez le résultat de nuitka --help . Inclure moins de modules dans la compilation, mais utiliser plutôt Python normal pour cela, accélérera la compilation.
Dans le cas où vous disposez d'un répertoire source avec des fichiers chargés dynamiquement, c'est-à-dire un répertoire qui ne peut pas être trouvé de manière récursive après des instructions d'importation normales via PYTHONPATH (ce qui serait la méthode recommandée), vous pouvez toujours exiger qu'un répertoire donné soit également inclus dans le exécutable :
python -m nuitka --follow-imports --include-plugin-directory=plugin_dir program.py
Note
Si vous n'effectuez aucune importation dynamique, vous devez simplement définir votre PYTHONPATH au moment de la compilation.
Utilisez --include-plugin-directory uniquement si vous effectuez des appels __import__() que Nuitka ne peut pas prédire et qui proviennent d'un répertoire, pour tout ce qui concerne votre installation Python, utilisez --include-module ou --include-package .
Note
Le nom de fichier résultant sera program.exe sous Windows, program.bin sur d'autres plates-formes, mais --output-filename permet de le modifier.
Note
Le binaire résultant dépend toujours de CPython et des modules d'extension C utilisés en cours d'installation.
Si vous souhaitez pouvoir le copier sur une autre machine, utilisez --standalone et copiez le répertoire program.dist créé et exécutez le program.exe (Windows) ou program (autres plates-formes) placé à l'intérieur.
Si vous souhaitez compiler un seul module d'extension, il vous suffit de faire ceci :
python -m nuitka --module some_module.py
Le fichier résultant some_module.so peut alors être utilisé à la place de some_module.py .
Important
Le nom de fichier du module d'extension produit ne doit pas être modifié car Python insiste sur une fonction dérivée du nom de module comme point d'entrée, dans ce cas PyInit_some_module et renommer le fichier ne changera pas cela. Faites correspondre le nom de fichier du code source à ce que devrait être le nom binaire.
Note
Si le module d'extension et son code source se trouvent dans le même répertoire, le module d'extension est chargé. Les modifications apportées au code source ne prennent effet qu'une fois recompilées.
Note
L'option --follow-import-to fonctionne également, mais les modules inclus ne deviendront importables qu'après avoir importé le nom some_module . Si ces types d'importations sont invisibles pour Nuitka, par exemple créées dynamiquement, vous pouvez utiliser --include-module ou --include-package dans ce cas, mais pour les importations statiques, cela ne devrait pas être nécessaire.
Note
Un module d'extension ne peut jamais inclure d'autres modules d'extension. Vous devrez créer une roue pour que cela soit réalisable.
Note
Le module d'extension résultant ne peut être chargé que dans un CPython de la même version et n'inclut pas d'autres modules d'extension.
Si vous avez besoin de compiler un package complet et d'intégrer tous les modules, cela est également réalisable, utilisez Nuitka comme ceci :
python -m nuitka --module un_package --include-package=un_package
Note
L'inclusion du contenu du package doit être fournie manuellement ; sinon, le paquet est en grande partie vide. Vous pouvez être plus précis si vous le souhaitez, et n'en inclure qu'une partie, ou en exclure une partie, par exemple avec --nofollow-import-to='*.tests' vous n'incluez pas la partie test inutilisée de votre code.
Note
Les fichiers de données situés à l'intérieur du package ne seront pas intégrés par ce processus, vous devez les copier vous-même avec cette approche. Alternativement, vous pouvez utiliser l'intégration de fichiers de Nuitka commercial.
Pour la distribution sur d'autres systèmes, il existe le mode autonome, qui produit un dossier pour lequel vous pouvez spécifier --standalone .
python -m nuitka --standalone program.py
Le suivi de toutes les importations est par défaut dans ce mode. Vous pouvez exclure sélectivement des modules en disant spécifiquement --nofollow-import-to , mais une ImportError sera alors générée lors de la tentative d'importation de celui-ci au moment de l'exécution du programme. Cela peut entraîner un comportement différent, mais cela peut également améliorer votre temps de compilation si cela est fait judicieusement.
Pour que les fichiers de données soient inclus, utilisez l'option --include-data-files=<source>=<target> où la source est un chemin du système de fichiers, mais la cible doit être spécifiée relative. Pour le mode autonome, vous pouvez également les copier manuellement, mais cela peut effectuer des vérifications supplémentaires, et pour le mode monofichier, aucune copie manuelle n'est possible.
Pour copier tout ou partie des fichiers dans un répertoire, utilisez l'option --include-data-files=/etc/*.txt=etc/ où vous pouvez spécifier des modèles de shell pour les fichiers et un sous-répertoire où les placer, indiqué par la barre oblique finale.
Important
Nuitka ne considère pas le code des fichiers de données, n'inclut pas les DLL ou les fichiers Python comme fichiers de données, et s'attend à ce qu'ils fonctionnent, ils ne le feront pas, à moins que vous ne sachiez vraiment ce que vous faites.
Dans ce qui suit, les fichiers de données non codés sont tous des fichiers ne correspondant pas à ces critères.
| Suffixe | Raisonnement | Solution |
|---|---|---|
.py | Nuitka supprime même les modules stdlib pour les inclure. S'il ne voit pas le code Python, aucune dépendance n'est analysée et, par conséquent, cela ne fonctionnera tout simplement pas. | Utilisez plutôt --include-module sur eux |
.pyc | Identique à .py . | Utilisez plutôt --include-module sur eux à partir de leur code source. |
.pyo | Identique à .pyc . | Utilisez plutôt --include-module sur eux à partir de leur code source. |
.pyw | Identique à .py . | Pour inclure plusieurs programmes, utilisez plutôt plusieurs arguments --main . |
.pyi | Ceux-ci sont ignorés, car ils ressemblent à du code et ne sont pas nécessaires au moment de l'exécution. Pour le package lazy qui en dépendrait réellement, nous avons créé une solution de compilation qui supprime ce besoin. | Soulevez un problème si un logiciel tiers en a besoin. |
.pyx | Ceux-ci sont ignorés, car il s'agit de code source Cython non utilisé au moment de l'exécution. | |
.dll | Ceux-ci sont ignorés car ce ne sont généralement pas des fichiers de données. Pour les cas où des packages tiers les utilisent réellement comme données, par exemple des packages .NET , nous résolvons ce problème dans la configuration du package. | Créez la configuration du package Nuitka pour ceux-ci, avec la section dll pour le package qui les utilise. Dans de rares cas, une section de fichiers de données avec une configuration spéciale peut être la bonne chose à faire. |
.dylib | Ceux-ci sont ignorés, car il s’agit de modules d’extension macOS ou de DLL. | Besoin d'ajouter une configuration avec la section dll ou depends manquantes |
.so | Ceux-ci sont ignorés, car il s'agit de modules d'extension ou de DLL Linux, BSD, etc. | Besoin d'ajouter une configuration avec la section dll ou depends manquantes |
.exe | Ce sont des binaires pour Windows. | Vous pouvez ajouter la configuration du package Nuitka pour les inclure sous forme de DLL et les marquer comme executable: yes |
.bin | Ce sont des binaires non-Windows, sinon identiques à .exe . |
Les dossiers sont également ignorés, il s'agit site-packages , dist-packages et vendor-packages qui autrement incluraient un virtualenv complet, ce qui n'est jamais une bonne chose. Et le dossier __pycache__ est également toujours ignoré. Sur les systèmes non MacOS, le fichier .DS_Store est également ignoré, et les dossiers py.typed n'ont de sens que pour les IDE et sont ignorés comme les fichiers .pyi .
Pour copier un dossier entier avec tous les fichiers non codés, vous pouvez utiliser --include-data-dir=/path/to/images=images qui les placera dans la destination, et si vous souhaitez utiliser le --noinclude-data-files option --noinclude-data-files pour les supprimer. Les fichiers de code sont comme détaillés ci-dessus les DLL, les exécutables, les fichiers Python, etc. et seront ignorés. Pour ceux-là, vous pouvez utiliser le formulaire --include-data-files=/binaries/*.exe=binary/ pour les forcer, mais cela n'est pas recommandé et est connu pour causer des problèmes au moment de l'exécution.
Pour les données de package, il existe un meilleur moyen, à savoir utiliser --include-package-data , qui détecte automatiquement tous les fichiers de données non codés des packages et les copie. Il accepte même les modèles de style coque. Cela vous évite d'avoir à trouver vous-même le répertoire du package et doit être préféré chaque fois qu'il est disponible. Fonctionnellement, il est très similaire à --include-data-dir mais il présente l'avantage de localiser le bon dossier pour vous.
Avec les fichiers de données, vous êtes en grande partie seul. Nuitka garde une trace de ceux qui sont nécessaires aux packages populaires, mais cela peut être incomplet. Soulevez des problèmes si vous rencontrez quelque chose dans ceux-ci. Mieux encore, augmentez les PR grâce aux améliorations apportées à la configuration du package Nuitka. Nous voulons que les logiciels tiers fonctionnent immédiatement.
Lorsque cela fonctionne, vous pouvez utiliser le mode onefile si vous le souhaitez.
python -m nuitka --onefile programme.py
Cela créera un seul binaire, qui s'extrait sur la cible, avant d'exécuter le programme. Mais notez que l'accès aux fichiers relatifs à votre programme est impacté, assurez-vous de lire également la section Onefile : Rechercher des fichiers.
# Créez un binaire qui se décompresse dans un dossier temporairepython -m nuitka --onefile program.py
Note
Il existe des options plus spécifiques à la plate-forme, par exemple liées aux icônes, à l'écran de démarrage et aux informations de version, considérez la sortie --help pour les détails de celles-ci et consultez la section Ajustements.
Pour le déballage, par défaut, un chemin temporaire utilisateur unique est utilisé, puis supprimé, cependant ce chemin par défaut --onefile-tempdir-spec="{TEMP}/onefile_{PID}_{TIME}" peut être remplacé par un chemin spécification, puis en utilisant un chemin mis en cache, en évitant les décompressions répétées, par exemple avec --onefile-tempdir-spec="{CACHE_DIR}/{COMPANY}/{PRODUCT}/{VERSION}" qui utilise la version informations et répertoire de cache spécifique à l'utilisateur.
Note
L'utilisation de chemins mis en cache sera pertinente, par exemple lorsque le pare-feu Windows entre en jeu, car sinon, le binaire sera différent à chaque fois qu'il sera exécuté.
Actuellement, ces jetons étendus sont disponibles :
| Jeton | À quoi cela s'étend-il | Exemple |
|---|---|---|
| {TEMP} | Répertoire de fichiers temporaires utilisateur | C:Utilisateurs...AppDataLocalsTemp |
| {PID} | ID de processus | 2772 |
| {TEMPS} | Temps en secondes depuis l'époque. | 1299852985 |
| {PROGRAMME} | Nom de fichier d'exécution complet du programme de l'exécutable. | C:SomeWhereYourOnefile.exe |
| {PROGRAM_BASE} | Aucun suffixe du nom de fichier d'exécution de l'exécutable. | C: SomeWhereYourOnefile |
| {CACHE_DIR} | Répertoire de cache pour l'utilisateur. | C:UtilisateursSomeBodyAppDataLocal |
| {ENTREPRISE} | Valeur donnée sous la forme --company-name | VotreNomEntreprise |
| {PRODUIT} | Valeur donnée sous la forme --product-name | VotreNomDeProduit |
| {VERSION} | Combinaison de --file-version et --product-version | 3.0.0.0-1.0.0.0 |
| {MAISON} | Répertoire personnel de l'utilisateur. | /maison/quelqu'un |
| {AUCUN} | Lorsqu'il est fourni pour les sorties de fichiers, None n'est utilisé | voir avis ci-dessous |
| {NUL} | Lorsqu'il est fourni pour les sorties de fichiers, os.devnull est utilisé | voir avis ci-dessous |
Important
Il est de votre responsabilité de rendre le chemin fourni unique, sous Windows, un programme en cours d'exécution sera verrouillé, et bien que l'utilisation d'un nom de dossier fixe soit possible, cela peut provoquer des problèmes de verrouillage dans ce cas, lorsque le programme est redémarré.
Habituellement, vous devez utiliser {TIME} ou au moins {PID} pour rendre un chemin unique, et ceci est principalement destiné aux cas d'utilisation, où par exemple vous souhaitez que les choses résident dans un endroit que vous choisissez ou respectez vos conventions de dénomination.
Important
Pour désactiver la sortie et stderr avec --force-stdout-spec et --force-stderr-spec les valeurs {NONE} et {NULL} y parviennent, mais avec un effet différent. Avec {NONE} , le handle correspondant devient None . En conséquence, par exemple, sys.stdout sera None , ce qui est différent de {NULL} où il sera sauvegardé par un fichier pointant vers os.devnull , c'est-à-dire que vous pourrez y écrire.
Avec {NONE} , vous pouvez par exemple obtenir RuntimeError: lost sys.stdout au cas où il serait utilisé ; avec {NULL} cela n'arrive jamais. Cependant, certaines bibliothèques gèrent cela comme entrée pour leur mécanisme de journalisation, et sous Windows, c'est ainsi que vous êtes compatible avec pythonw.exe qui se comporte comme {NONE} .
Si vous disposez d'une création de roues pilotée par setup.py , setup.cfg ou pyproject.toml pour votre logiciel, l'utilisation de Nuitka est extrêmement simple.
Commençons par l'approche setuptools la plus courante, vous pouvez, après avoir installé Nuitka bien sûr, simplement exécuter la cible bdist_nuitka plutôt que la bdist_wheel . Il reprend toutes les options et permet d'en spécifier d'autres, spécifiques à Nuitka.
# Pour setup.py si vous n'utilisez pas d'autres systèmes de build :setup( # Les fichiers de données doivent être gérés par setuptools et non par Nuitka
package_data={"some_package": ["some_file.txt"]},
..., # C'est pour passer les options Nuitka.
command_options={ 'nuitka' : { # option booléenne, par exemple si vous tenez aux commandes de compilation C '--show-scons' : True, # options sans valeur, par exemple appliquer en utilisant Clang '--clang' : Aucune, # options avec valeurs uniques, par exemple activer un plugin de Nuitka '--enable-plugin' : "pyside2", # options avec plusieurs valeurs, par exemple éviter d'inclure des modules '--nofollow-import-to' : ["*.tests", "*.distutils"],
},
},
)# Pour setup.py avec d'autres systèmes de build :# La nature tuple des arguments est requise par la nature sombre de# "setuptools" et de ses plugins, qui insistent sur une compatibilité totale,# par exemple "setuptools_rust"setup( # Fichiers de données doivent être gérés par setuptools et non par Nuitka
package_data={"some_package": ["some_file.txt"]},
..., # C'est pour passer les options Nuitka.
..., command_options={ 'nuitka': { # option booléenne, par exemple si vous vous souciez des commandes de compilation C '--show-scons': ("setup.py", True), # options sans valeur, par exemple appliquer en utilisant Clang '--clang' : ("setup.py", Aucun), # options avec des valeurs uniques, par exemple activer un plugin de Nuitka '--enable-plugin' : ("setup.py", "pyside2"), # choix avec plusieurs valeurs, par exemple éviter d'inclure les modules '--nofollow-import-to' : ("setup.py", ["*.tests", "*.distutils"]),
}
},
) Si, pour une raison quelconque, vous ne pouvez pas ou ne souhaitez pas modifier la cible, vous pouvez l'ajouter à votre setup.py .
# Pour setup.pysetup( ..., build_with_nuitka=Vrai)
Note
Pour désactiver temporairement la compilation, vous pouvez supprimer la ligne ci-dessus, ou modifier la valeur sur False ou prendre sa valeur à partir d'une variable d'environnement si vous le souhaitez, par exemple bool(os.getenv("USE_NUITKA", "True")) . Cela dépend de vous.
Ou vous pouvez le mettre dans votre setup.cfg
[métadonnées]build_with_nuitka = true
Et enfin, Nuitka prend également en charge la nouvelle méta build , donc lorsque vous avez déjà un pyproject.toml , remplacez simplement ou ajoutez cette valeur :
[build-system]requires = ["setuptools>=42", "wheel", "nuitka", "toml"]build-backend = "nuitka.distutils.Build"# Les fichiers de données doivent être gérés par setuptools et non par Nuitka [tool.setuptools.package-data]some_package = ['data_file.txt'] [tool.nuitka]# Celles-ci ne sont pas recommandées, mais elles rendent leur effet évident.# option booléenne, par exemple si vous vous souciez des commandes de compilation C, les tirets de début sont omisshow-scons = true# options avec des valeurs uniques, par exemple activer un plugin de Nuitkaenable-plugin = "pyside2"# options avec plusieurs valeurs, par exemple éviter d'inclure des modules, accepte# list argument.nofollow-import-to = ["*.tests", "*.distutils"]
Note
Pour l'exigence nuitka au-dessus des chemins absolus comme C:Users...Nuitka fonctionnera également sous Linux, utilisez un chemin absolu avec deux barres obliques, par exemple //home/.../Nuitka .
Note
Quelle que soit l'approche que vous adoptez, les fichiers de données de ces roues ne sont pas du tout gérés par Nuitka, mais par setuptools. Vous pouvez cependant utiliser le fichier de données incorporé de Nuitka commercial. Dans ce cas, vous intégreriez les fichiers dans le module d'extension lui-même, et non sous forme de fichier dans la roue.
Si vous avez plusieurs programmes, chacun devant être exécutable, dans le passé, vous deviez compiler plusieurs fois et déployer tous ces programmes. Avec le mode autonome, cela signifiait bien sûr que vous gaspilliez beaucoup, car le partage des dossiers pouvait être effectué, mais n'était pas vraiment pris en charge par Nuitka.
Entrez Multidist . Il existe une option --main qui remplace ou ajoute à l'argument de position donné. Et cela peut être donné plusieurs fois. Lorsqu'il est donné plusieurs fois, Nuitka créera un binaire qui contient le code de tous les programmes donnés, mais partageant les modules utilisés dans ceux-ci. Il n’est donc pas nécessaire de les distribuer plusieurs fois.
Appelons le nom de base du chemin principal et le point d'entrée. Les noms de ceux-ci doivent bien entendu être différents. Ensuite, le binaire créé peut exécuter l'un ou l'autre point d'entrée et réagira à ce que sys.argv[0] lui apparaît. Donc, s'il est exécuté de la bonne manière (avec quelque chose comme subprocess ou une API du système d'exploitation, vous pouvez contrôler ce nom), ou en renommant ou en copiant le binaire, ou en créant un lien symbolique vers celui-ci, vous pouvez alors réaliser le miracle.
Cela permet de combiner des programmes très différents en un seul.
Note
Cette fonctionnalité est encore expérimentale. Utilisez-le avec précaution et signalez vos résultats si vous rencontrez un comportement indésirable.
Ce mode fonctionne de manière autonome, avec un seul fichier et avec une simple accélération. Cela ne fonctionne pas avec le mode module.
Pour l'intégration avec les workflows GitHub, vous devez utiliser cette Nuitka-Action qui le rend vraiment facile à intégrer. Vous devriez cependant commencer par une compilation locale, mais ce sera plus simple pour une compilation multiplateforme avec Nuitka.
Il s'agit d'un exemple de flux de travail qui s'appuie sur les 3 systèmes d'exploitation
jobs:build: stratégie: matrice: os: [macos-latest, ubuntu-latest, windows-latest]
exécution : ${{matrix.os }}
mesures:
- nom : Le référentiel d'extraction utilise : actions/checkout@v4 - nom : Configuration Python utilise : actions/setup-python@v5 avec : version python : '3.10' cache : 'pip' chemin-de-dépendance du cache : | **/requirements*.txt - nom : Installez vos dépendances, exécutez : | pip install -r exigences.txt -r exigences-dev.txt - nom : Build Executable avec Nuitka utilise : Nuitka/Nuitka-Action@main avec : nuitka-version : main script-name : your_main_program.py # de nombreuses autres options Nuitka disponibles , voir le document d'action, mais il est préférable # d'utiliser les options nuitka-project: dans votre code, afin que par exemple vous puissiez faire # une différence pour macOS et y créer un ensemble d'applications. onefile : true - nom : Upload Artifacts utilise : actions/upload-artifact@v3 avec : nom : ${{ runner.os }} Chemin de construction : | # correspond à ce qui est créé pour les 3 OS build/*.exe build/*.bin build/*.app/**/* Si votre application est une interface graphique, par exemple your_main_program.py doit contenir ces commentaires comme expliqué dans les options Nuitka dans le code, car sur macOS, cela devrait alors être un bundle.
# Mode compilation, autonome partout, sauf sur macOS il y a app bundle# nuitka-project-if: {OS} dans ("Windows", "Linux", "FreeBSD"):# nuitka-project: --onefile# nuitka-project -if : {OS} == "Darwin":# nuitka-project: --standalone# nuitka-project: --macos-create-app-bundle#Pour une meilleure apparence, vous pouvez spécifier des icônes. Sous Windows, vous pouvez fournir un fichier icône, un modèle exécutable ou un fichier PNG. Tous ces éléments fonctionneront et pourront même être combinés :
# Ceux-ci créent des binaires avec des icônes sur Windowspython -m nuitka --onefile --windows-icon-from-ico=your-icon.png program.py python -m nuitka --onefile --windows-icon-from-ico=votre-icon.ico program.py python -m nuitka --onefile --windows-icon-template-exe=your-icon.ico program.py# Ceux-ci créent des bundles d'applications avec des icônes sur macOSpython -m nuitka --macos-create-app-bundle --macos- app-icon=votre-icon.png program.py python -m nuitka --macos-create-app-bundle --macos-app-icon=your-icon.icns program.py
Note
Avec Nuitka, vous n'avez pas besoin de créer d'icônes spécifiques à la plate-forme, mais il convertira par exemple PNG, mais également d'autres formats à la volée lors de la construction.
Les droits pour un ensemble d'applications macOS peuvent être ajoutés avec l'option --macos-app-protected-resource , toutes les valeurs sont répertoriées sur cette page d'Apple
Un exemple de valeur serait --macos-app-protected-resource=NSMicrophoneUsageDescription:Microphone access pour demander l'accès à un microphone. Après les deux points, le texte descriptif doit être donné.
Note
Attention, dans le cas probable d'utilisation d'espaces dans la partie description, vous devez les citer pour que votre shell puisse accéder à Nuitka et ne soit pas interprété comme des arguments de Nuitka.
Sous Windows, la console n'est pas ouverte par les programmes sauf si vous le dites. Nuitka ne l'affiche pas par défaut, vous pouvez le forcer en utilisant --console=force , puis le programme ouvrira une nouvelle fenêtre de terminal lors de son exécution.
Les écrans de démarrage sont utiles lorsque le démarrage du programme est lent. Le démarrage de Onefile en lui-même n'est pas lent, mais votre programme peut l'être, et vous ne pouvez pas vraiment savoir à quelle vitesse l'ordinateur sera utilisé, cela pourrait donc être une bonne idée de les avoir. Heureusement, avec Nuitka, ils sont faciles à ajouter pour Windows.
Pour l'écran de démarrage, vous devez le spécifier sous forme de fichier PNG, puis assurez-vous de désactiver l'écran de démarrage lorsque votre programme est prêt, par exemple lorsqu'il a terminé les importations, préparé la fenêtre, connecté à la base de données et souhaite afficher l'écran de démarrage. s'en aller. Ici, nous utilisons la syntaxe du projet pour combiner le code avec la création, compilez ceci :
# nuitka-project: --onefile# nuitka-project: --onefile-windows-splash-screen-image={MAIN_DIRECTORY}/Splash-Screen.png# Quoi qu'il en soit, évidemmentprint("Retarder le démarrage de 10 s..." )import time, tempfile, ostime.sleep(10)# Utilisez ce code pour signaler la suppression de l'écran de démarrage.if "NUITKA_ONEFILE_PARENT" dans os.environ : splash_filename = os.path.join( tempfile.gettempdir(), "onefile_%d_splash_feedback.tmp" % int(os.environ["NUITKA_ONEFILE_PARENT"]),
) if os.path.exists(splash_filename): os.unlink(splash_filename)print("Terminé... le splash devrait disparaître.")
...# Le reste de votre programme va ici.Pour l’analyse de votre programme et du packaging Nuitka, le rapport de compilation est disponible. Vous pouvez également créer des rapports personnalisés en fournissant votre modèle, dont quelques-uns sont intégrés à Nuitka. Ces rapports contiennent toutes les informations détaillées, par exemple lorsqu'un module a été tenté d'être importé, mais n'a pas été trouvé, vous pouvez voir où cela se produit. Pour le rapport de bug, il est fortement recommandé de fournir le rapport.
Vous pouvez joindre des informations sur les droits d'auteur et les marques, le nom de l'entreprise, le nom du produit, etc. à votre compilation. Ceci est ensuite utilisé dans les informations de version du binaire créé sous Windows ou du bundle d'applications sous macOS. Si vous trouvez quelque chose qui manque, veuillez nous le faire savoir.
Par défaut, Nuitka compile sans --deployment , ce qui laisse un ensemble de protections et d'aides activés, destinés à déboguer les mauvaises utilisations de Nuitka.
Il s'agit d'une nouvelle fonctionnalité qui implémente un ensemble de protections et d'assistances, qui sont documentées ici.
Ainsi, après compilation, sys.executable est le binaire compilé. Dans le cas de packages comme multiprocessing , joblib ou loky ce que ceux-ci font généralement, c'est s'attendre à exécuter à partir d'un python complet avec sys.executable , puis de pouvoir utiliser ses options comme -c command ou -m module_name , puis être en mesure de Lancez un autre code temporairement ou en permanence en tant que démon de service.
Avec Nuitka cependant, cela exécute à nouveau votre programme, et met ces arguments, dans sys.argv où vous les ignorez peut-être, puis vous vous débarrassez à nouveau pour lancer les démons d'aide. Parfois, cela finit par répartir les processus de comptage du processeur qui engendrent des processus de comptage du processeur qui ... cela s'appelle une bombe à fourche, et avec presque tous les systèmes, qui les gèle facilement à mort.
C'est pourquoi, par exemple, cela se produit avec Nuitka par défaut:
./hello.dist/hello.bin -l Fool -M Foom -n Foon -o fooo -p Erreur, le programme a essayé de s'appeler avec l'argument «-m». Désactiver avec '--o-déploiement-flat = auto-exécution'.
Votre programme peut bien avoir son propre analyse de ligne de commande et ne pas utiliser un package non pris en charge qui tente de réexécuter. Dans ce cas, vous avez besoin de compiler le temps pour utiliser --no-deployment-flag=self-execution qui désactive ce garde spécifique.
Certains packages produisent ce qu'ils pensent être des informations utiles sur la raison pour laquelle la raison d'une importation infructueuse pourrait signifier. Avec des programmes compilés, il y a très souvent tout simplement mal. Nous essayons de réparer ceux en mode non déploiement. Voici un exemple où nous modifions un message qui demande à PIP Installer (qui n'est pas le problème) pour pointer l'utilisateur vers la commande include qui fait fonctionner un plugin imageio .
- nom de module: 'imageo.core.imopen'
anti-calcul:
- Remplacements_plain: '`pip install ImageIo [{config.install_name}]` pour l'installer': '`--include-module = {config.module_name}` avec nuitka pour inclure it''err_type = Importrror': 'err_type = RunTimeError 'quand:' pas de déploiement ' Le mode de déploiement est relativement nouveau et a constamment plus de fonctionnalités ajoutées, par exemple quelque chose pour FileNotFoundError devrait arriver bientôt.
Tous ces aides peuvent bien sûr être désactivés en même temps avec --deployment , mais gardez à l'esprit que pour le débogage, vous voudrez peut-être le réactiver. Vous voudrez peut-être utiliser les options de projet Nuitka et une variable d'environnement pour faire ce conditionnel.
Devriez-vous les désactiver tous?
Nous pensons que la désactivation ne devrait se produire que sélectivement, mais avec les mises à niveau PYPI, vos changements de code, tous ces problèmes peuvent se faufiler. L'économie d'espace du mode de déploiement est actuellement négligeable, alors essayez de ne pas le faire, mais passez en revue ce qui existe, et Si vous savez que cela ne peut pas vous affecter ou si c'est le cas, vous n'en aurez pas besoin. Certains des futurs seront clairement destinés à l'utilisation au niveau débutant.
Les binaires compilés sous Windows avec des paramètres par défaut de Nuitka et aucune autre action effectuée ne peuvent être reconnus par certains fournisseurs AV comme malware. Ceci est évitable, mais uniquement dans la publicité Nuitka, il y a un soutien réel et des instructions sur la façon de le faire, en voyant cela comme un besoin commercial typique uniquement. https://nuitka.net/doc/commercial.html
Pour Linux autonome, il est assez difficile de construire un binaire qui fonctionne sur d'autres versions Linux. Cela est principalement dû au fait que sur Linux, beaucoup de logiciels sont construits spécifiquement ciblés sur des DLL en béton. Des choses comme GLIBC utilisées sont ensuite codées dans le binaire construit, et il ne fonctionnera pas avec un GLIBC plus ancien, juste pour donner un exemple critique.
La solution consiste à construire sur le système d'exploitation le plus ancien que vous souhaitez voir pris en charge. Choisir cela et le configurer peut être fastidieux, donc peut être connecté, et le garder
