Nuitka
1.0.0
Este documento es la primera lectura recomendada cuando empiece a utilizar Nuitka . En esta página, aprenderá más sobre los fundamentos de Nuitka , como el tipo de licencia, los casos de uso, los requisitos y los créditos.
Tabla de contenido
Requisitos
Uso
Tutorial de configuración y compilación en Windows
Casos de uso
Ajustes
Problemas típicos
Consejos
Informe de compilación
Actuación
Funcionalidad no compatible
Nuitka es el compilador de Python. Está escrito en Python. Es un reemplazo o extensión perfecta del intérprete de Python y compila todas las construcciones que tienen Python 2 (2.6, 2.7) y Python 3 (3.4 - 3.13), cuando se ejecutan con esa versión de Python.
Luego ejecuta código no compilado y código compilado juntos de una manera extremadamente compatible.
Puede utilizar todos los módulos de la biblioteca de Python y todos los módulos de extensión libremente.
Nuitka traduce los módulos de Python a un programa de nivel C que luego usa libpython y sus propios archivos C estáticos para ejecutarse de la misma manera que lo hace CPython.
Toda optimización tiene como objetivo evitar gastos generales cuando no es necesario. Ninguno tiene como objetivo eliminar la compatibilidad, aunque ocasionalmente se realizarán ligeras mejoras, donde no se emula todos los errores del Python estándar, por ejemplo, se dan mensajes de error más completos, pero hay un modo de compatibilidad total para desactivar incluso eso.
Para garantizar el buen funcionamiento de Nuitka , asegúrese de seguir los requisitos del sistema, que incluyen los siguientes componentes:
Compilador C
Pitón
Sistema operativo
Arquitectura
Necesita un compilador de C compatible con C11 o, alternativamente, un compilador de C++ para C++03 [1].
Actualmente, esto significa que necesitas usar uno de estos compiladores:
El compilador MinGW64 C11, en Windows, debe estar basado en gcc 11.2 o superior. Se descargará automáticamente si no se encuentra ningún compilador de C utilizable, que es la forma recomendada de instalarlo, ya que Nuitka también lo actualizará por usted.
Visual Studio 2022 o superior en Windows [2]. Paquete de idioma inglés para obtener mejores resultados (Nuitka filtra los resultados basura, pero solo para el idioma inglés). Se utilizará de forma predeterminada si está instalado.
En todas las demás plataformas, el compilador gcc de al menos la versión 5.1 y, debajo, el compilador g++ de al menos la versión 4.4 como alternativa.
El compilador clang en macOS X y la mayoría de las arquitecturas FreeBSD.
En Windows, se puede utilizar el compilador clang-cl si lo proporciona el instalador de Visual Studio.
| [1] | El soporte para este C11 se brinda con gcc 5.x o superior o cualquier versión clang. Los compiladores MSVC más antiguos aún no lo hacen. Pero como solución alternativa, con Python 3.10 o anterior, el estándar del lenguaje C++03 se superpone significativamente con C11, por lo que se utiliza en su lugar. |
| [2] | Descárguelo gratis desde https://www.visualstudio.com/en-us/downloads/download-visual-studio-vs.aspx (las ediciones comunitarias funcionan bien). Se recomienda la última versión, pero no es obligatoria. Por otro lado, no es necesario excepto admitir versiones anteriores a Windows 10, y es posible que funcionen para usted, pero la compatibilidad con estas configuraciones solo está disponible para usuarios comerciales. |
Se admiten Python 2 (2.6, 2.7) y Python 3 (3.4 - 3.13). Si en algún momento hay una versión estable de Python que no está en esta lista, tenga la seguridad de que se está trabajando en ella y se agregará.
Importante
Para Python 3.4 y solo esa versión, necesitamos otra versión de Python como dependencia en tiempo de compilación .
Nuitka en sí es totalmente compatible con todas las versiones enumeradas, pero Scons como herramienta de uso interno no lo es.
Para estas versiones, también necesita tener instalado Python2 o Python 3.5 o superior, pero solo durante el tiempo de compilación. Esto es para usar con Scons (que organiza la compilación de C), que no admite las mismas versiones de Python que Nuitka.
Además, en Windows, Python2 no se puede utilizar porque clcache no funciona con él; allí es necesario instalar Python 3.5 o superior.
Nuitka encuentra estas versiones necesarias de Python (por ejemplo, en Windows a través del registro) y usted no debería notarlo mientras estén instaladas.
Cada vez más, hay otras funciones disponibles cuando otro Python tiene un determinado paquete instalado. Por ejemplo, la compresión de un archivo funcionará para Python 2.x cuando se encuentre otro Python que tenga instalado el paquete zstandard .
Mover archivos binarios a otras máquinas
Los binarios creados se pueden hacer ejecutables independientemente de la instalación de Python, con las opciones --standalone y --onefile .
Sufijo de nombre de archivo binario
Los binarios creados tienen un sufijo .exe en Windows. En otras plataformas no tienen sufijo para el modo independiente, ni sufijo .bin , que usted puede eliminar o cambiar, o especificar con la opción -o .
El sufijo para el modo de aceleración se agrega solo para asegurarnos de que el nombre del script original y el nombre del binario nunca choquen, de modo que podamos sobrescribir el binario de forma segura sin destruir el archivo fuente original.
Tiene que ser CPython, Anaconda Python o Homebrew.
Necesita la implementación estándar de Python, llamada "CPython", para ejecutar Nuitka porque está estrechamente relacionada con los detalles de su implementación.
No puede ser de la tienda de aplicaciones de Windows.
Se sabe que Python en la tienda de aplicaciones de Windows definitivamente no funciona, está comprobado.
No puede ser pyev en macOS
Se sabe que macOS "pyenv" no funciona. Utilice Homebrew en su lugar para instalaciones de Python autocompiladas. Pero tenga en cuenta que el modo independiente será peor en estas plataformas y no será tan compatible con versiones anteriores de macOS.
Sistemas operativos compatibles: Linux, FreeBSD, NetBSD, macOS y Windows (32 bits/64 bits/ARM).
Otros también funcionarán. Se espera que la portabilidad sea buena en general, pero es posible que, por ejemplo, el uso interno de Scons de Nuitka deba adaptarse o sea necesario aprobar indicadores. Asegúrese de hacer coincidir la arquitectura del compilador de Python y C; de lo contrario, recibirá mensajes de error crípticos.
Las arquitecturas admitidas son x86, x86_64 (amd64) y arm, probablemente muchas, muchas más.
Se espera que otras arquitecturas también funcionen, listas para usar, ya que Nuitka generalmente no utiliza ningún hardware específico. Estos son sólo los que se han probado y se sabe que son buenos. Los comentarios son bienvenidos. Generalmente, las arquitecturas que admite Debian pueden considerarse buenas y probadas también.
La forma recomendada de ejecutar Nuitka es <the_right_python> -m nuitka para estar absolutamente seguro de qué intérprete de Python está utilizando, de modo que sea más fácil coincidir con lo que tiene Nuitka.
La siguiente mejor manera de ejecutar Nuitka es desde un archivo o extracción de código fuente, sin cambios en las variables de entorno. Lo más notable es que no tiene que meterse con PYTHONPATH en absoluto para Nuitka. Simplemente ejecute los scripts nuitka y nuitka-run directamente sin ningún cambio en el entorno. Es posible que desee agregar el directorio bin a su PATH para su conveniencia, pero ese paso es opcional.
Además, si desea ejecutar con el intérprete correcto, en ese caso, asegúrese de ejecutar <the_right_python> bin/nuitka y sea bueno.
Elija el intérprete adecuado
Si encuentra un SyntaxError lo más seguro es que haya elegido el intérprete incorrecto para el programa que está compilando.
Nuitka tiene una opción --help para mostrar lo que puede hacer:
nuitka --ayuda
El comando nuitka-run es el mismo que nuitka , pero con un valor predeterminado diferente. Intenta compilar y ejecutar directamente un script de Python:
nuitka-run --ayuda
Esta opción que es diferente es --run y pasa argumentos después de la primera no opción al binario creado, por lo que es algo más similar a lo que hará python simple.
Para la mayoría de los sistemas, habrá paquetes en la página de descarga de Nuitka. Pero también puede instalarlo desde el código fuente como se describe anteriormente, pero también, como cualquier otro programa Python, puede instalarse mediante la rutina python setup.py install .
Aviso para la integración con los flujos de trabajo de GitHub, existe esta Nuitka-Action que debes usar y que hace que sea realmente fácil de integrar. Deberías comenzar con una compilación local, pero será más fácil para la compilación multiplataforma con Nuitka.
Nuitka tiene la licencia Apache, versión 2.0; no puede utilizarlo excepto de conformidad con la Licencia.
Puede obtener una copia de la Licencia en http://www.apache.org/licenses/LICENSE-2.0
A menos que lo exija la ley aplicable o se acuerde por escrito, el software distribuido bajo la Licencia se distribuye "TAL CUAL", SIN GARANTÍAS NI CONDICIONES DE NINGÚN TIPO, ya sean expresas o implícitas. Consulte la Licencia para conocer el idioma específico que rige los permisos y limitaciones de la Licencia.
Estos son pasos básicos si no tienes nada instalado, por supuesto, si tienes alguna de las piezas, simplemente omítelo.
Descargue e instale Python desde https://www.python.org/downloads/windows
Seleccione uno de Windows x86-64 web-based installer (Python de 64 bits, recomendado) o x86 executable (Python de 32 bits).
Verifique que esté funcionando usando el comando python --version .
python -m pip install nuitka
Verifique usando el comando python -m nuitka --version
mkdir Hola Mundo
crea un archivo Python llamado hola.py
def hablar(mensaje):return "Hablar " + mensajedef main():print(hablar("Hola mundo"))if __name__ == "__main__":main()Haz lo que normalmente harías. Ejecutar Nuitka en código que funciona incorrectamente no es más fácil de depurar.
python hola.py
python -m nuitka hola.py
Nota
Esto le pedirá que descargue una herramienta de almacenamiento en caché de C (para acelerar la compilación repetida del código C generado) y un compilador de C basado en MinGW64, a menos que tenga instalado un MSVC adecuado. Responda yes a ambas preguntas.
Ejecute el hello.exe creado cerca de hello.py .
Para distribuir, compila con la opción --standalone , que no generará un solo ejecutable, sino una carpeta completa. Copie la carpeta hello.dist resultante a la otra máquina y ejecútela.
También puede probar --onefile , que crea un único archivo, pero asegúrese de que el independiente esté funcionando antes de recurrir a él, ya que hará que la depuración sea más difícil, por ejemplo, en caso de que falten archivos de datos.
Si desea compilar un programa completo de forma recursiva, y no solo el archivo único que es el programa principal, hágalo así:
python -m nuitka --follow-imports program.py
Nota
Hay controles más detallados que --follow-imports disponibles. Considere el resultado de nuitka --help . Incluir menos módulos en la compilación, pero en lugar de usar Python normal, hará que la compilación sea más rápida.
En caso de que tenga un directorio fuente con archivos cargados dinámicamente, es decir, uno que no se pueda encontrar recurriendo después de declaraciones de importación normales a través de PYTHONPATH (que sería la forma recomendada), siempre puede solicitar que un directorio determinado también se incluya en el ejecutable:
python -m nuitka --follow-imports --include-plugin-directory=plugin_dir programa.py
Nota
Si no realiza ninguna importación dinámica, lo que debe hacer es simplemente configurar su PYTHONPATH en el momento de la compilación.
Use --include-plugin-directory solo si realiza llamadas __import__() que Nuitka no puede predecir y que provienen de un directorio; para todo, desde su instalación de Python, use --include-module o --include-package .
Nota
El nombre de archivo resultante será program.exe en Windows, program.bin en otras plataformas, pero --output-filename permite cambiar eso.
Nota
El binario resultante aún depende de CPython y de los módulos de extensión C usados que se instalen.
Si desea poder copiarlo a otra máquina, use --standalone y copie el directorio program.dist creado y ejecute el program.exe (Windows) o program (otras plataformas) que se encuentra dentro.
Si deseas compilar un único módulo de extensión, todo lo que tienes que hacer es esto:
python -m nuitka --module some_module.py
El archivo resultante some_module.so se puede utilizar en lugar de some_module.py .
Importante
El nombre de archivo del módulo de extensión producido no debe cambiarse ya que Python insiste en una función derivada del nombre del módulo como punto de entrada; en este caso, PyInit_some_module y cambiar el nombre del archivo no cambiarán eso. Haga coincidir el nombre de archivo del código fuente con el que debería ser el nombre binario.
Nota
Si tanto el módulo de extensión como su código fuente están en el mismo directorio, se carga el módulo de extensión. Los cambios en el código fuente solo tienen efecto una vez que se vuelve a compilar.
Nota
La opción --follow-import-to también funciona, pero los módulos incluidos solo se podrán importar después de que hayas importado el nombre de some_module . Si este tipo de importaciones son invisibles para Nuitka, por ejemplo, creadas dinámicamente, puede usar --include-module o --include-package en ese caso, pero para importaciones estáticas no debería ser necesario.
Nota
Un módulo de extensión nunca puede incluir otros módulos de extensión. Tendrás que crear una rueda para que esto sea posible.
Nota
El módulo de extensión resultante solo se puede cargar en un CPython de la misma versión y no incluye otros módulos de extensión.
Si necesita compilar un paquete completo e incrustar todos los módulos, eso también es factible, use Nuitka de esta manera:
python -m nuitka --module algún_paquete --include-package=algún_paquete
Nota
La inclusión del contenido del paquete debe realizarse manualmente; de lo contrario, el paquete estará prácticamente vacío. Puede ser más específico si lo desea e incluir solo una parte o excluirla; por ejemplo, con --nofollow-import-to='*.tests' no incluiría la parte de prueba no utilizada de su código.
Nota
Los archivos de datos ubicados dentro del paquete no se incrustarán en este proceso; deberá copiarlos usted mismo con este método. Alternativamente, puede utilizar la incrustación de archivos del comercial de Nuitka.
Para la distribución a otros sistemas, existe el modo independiente, que genera una carpeta para la que puede especificar --standalone .
python -m nuitka --programa independiente.py
Seguir todas las importaciones es predeterminado en este modo. Puede excluir módulos de forma selectiva diciendo específicamente --nofollow-import-to , pero luego se generará un ImportError cuando se intente importarlo en tiempo de ejecución del programa. Esto puede provocar un comportamiento diferente, pero también puede mejorar el tiempo de compilación si se hace con prudencia.
Para incluir archivos de datos, utilice la opción --include-data-files=<source>=<target> donde el origen es una ruta del sistema de archivos, pero el destino debe especificarse de forma relativa. Para el modo independiente, también puede copiarlos manualmente, pero esto puede realizar comprobaciones adicionales, y para el modo de un solo archivo, no es posible copiarlos manualmente.
Para copiar algunos o todos los archivos en un directorio, use la opción --include-data-files=/etc/*.txt=etc/ donde puede especificar patrones de shell para los archivos y un subdirectorio donde colocarlos, indicado por la barra diagonal final.
Importante
Nuitka no considera el código de los archivos de datos, no incluye archivos DLL ni archivos Python como archivos de datos, y espera que funcionen, pero no lo harán, a menos que realmente sepa lo que está haciendo.
A continuación, los archivos de datos sin código son todos archivos que no coinciden con ninguno de estos criterios.
| Sufijo | Razón fundamental | Solución |
|---|---|---|
.py | Nuitka recorta incluso los módulos stdlib que se incluirán. Si no ve el código Python, no se analizan las dependencias y, como resultado, simplemente no funcionará. | Utilice --include-module en su lugar |
.pyc | Igual que .py . | En su lugar, utilice --include-module desde su código fuente. |
.pyo | Igual que .pyc . | En su lugar, utilice --include-module desde su código fuente. |
.pyw | Igual que .py . | Para incluir múltiples programas, use múltiples argumentos --main en su lugar. |
.pyi | Estos se ignoran porque son similares a códigos y no son necesarios en tiempo de ejecución. Para el paquete lazy que realmente dependería de ellos, creamos una solución en tiempo de compilación que elimina la necesidad. | Plantee un problema si el software de terceros lo necesita. |
.pyx | Estos se ignoran porque son código fuente de Cython que no se utiliza en tiempo de ejecución. | |
.dll | Estos se ignoran, ya que normalmente no son archivos de datos. Para los casos en los que los paquetes de terceros realmente los utilizan como datos, por ejemplo, paquetes .NET , lo solucionamos en la configuración del paquete. | Cree la configuración del paquete Nuitka para aquellos, con una sección dll para el paquete que los utiliza. En casos excepcionales, la sección de archivos de datos con una configuración especial puede ser lo correcto. |
.dylib | Estos se ignoran, ya que son módulos de extensión o DLL de macOS. | Es necesario agregar configuración con la sección dll o depends de lo que falta |
.so | Estos se ignoran, ya que son módulos de extensión o DLL de Linux, BSD, etc. | Es necesario agregar configuración con la sección dll o depends de lo que falta |
.exe | Son binarios para Windows. | Puede agregar la configuración del paquete Nuitka para incluirlos como archivos DLL y marcarlos como executable: yes |
.bin | Son archivos binarios que no son de Windows; por lo demás, son iguales que .exe . |
También se ignoran las carpetas, que son site-packages , dist-packages y vendor-packages que de otro modo incluirían un entorno virtual completo, lo que nunca es bueno que suceda. Y la carpeta __pycache__ también siempre se ignora. En sistemas que no son MacOS, el archivo .DS_Store también se ignora y las carpetas py.typed solo tienen significado para los IDE y se ignoran como archivos .pyi .
Para copiar una carpeta completa con todos los archivos que no son de código, puede usar --include-data-dir=/path/to/images=images que los colocará en el destino, y si desea usar --noinclude-data-files opción --noinclude-data-files para eliminarlos. Los archivos de código son los detallados anteriormente: DLL, ejecutables, archivos Python, etc. y se ignorarán. Para aquellos, puede usar el formulario --include-data-files=/binaries/*.exe=binary/ para forzarlos, pero no se recomienda y se sabe que causa problemas en tiempo de ejecución.
Para los datos de paquetes, existe una mejor manera, es decir, usar --include-package-data , que detecta automáticamente todos los archivos de datos de paquetes que no son de código y los copia. Incluso acepta patrones en estilo concha. Le ahorra la necesidad de encontrar el directorio del paquete usted mismo y debería ser el preferido siempre que esté disponible. Funcionalmente es muy similar a --include-data-dir pero tiene la ventaja de localizar la carpeta correcta para usted.
Con los archivos de datos, en gran medida estás solo. Nuitka realiza un seguimiento de los que necesitan los paquetes populares, pero puede que estén incompletos. Plantee problemas si encuentra algo en estos. Aún mejor, aumente las relaciones públicas con mejoras en la configuración del paquete Nuitka. Queremos que el software de terceros funcione de inmediato.
Cuando eso esté funcionando, puede usar el modo onefile si así lo desea.
python -m nuitka --onefile programa.py
Esto creará un único binario, que se extrae en el objetivo antes de ejecutar el programa. Pero tenga en cuenta que el acceso a archivos relacionados con su programa se ve afectado; asegúrese de leer también la sección Onefile: Búsqueda de archivos.
# Crea un binario que se descomprime en una carpeta temporalpython -m nuitka --onefile program.py
Nota
Hay más opciones específicas de la plataforma, por ejemplo, relacionadas con íconos, pantalla de presentación e información de versión; considere la salida --help para obtener más detalles y consulte la sección Ajustes.
Para descomprimir, de forma predeterminada se utiliza una ruta temporal de usuario única y luego se elimina; sin embargo, esta --onefile-tempdir-spec="{TEMP}/onefile_{PID}_{TIME}" predeterminada se puede anular con una ruta especificación, luego usar una ruta en caché, evitando descomprimir repetidamente, por ejemplo, con --onefile-tempdir-spec="{CACHE_DIR}/{COMPANY}/{PRODUCT}/{VERSION}" que usa información de versión y caché específica del usuario directorio.
Nota
El uso de rutas en caché será relevante, por ejemplo, cuando el Firewall de Windows entre en juego porque, de lo contrario, el binario será diferente cada vez que se ejecute.
Actualmente, estos tokens ampliados están disponibles:
| Simbólico | A qué se expande esto | Ejemplo |
|---|---|---|
| {TEMPERATURA} | Directorio de archivos temporales del usuario | C:Usuarios...AppDataLocalsTemp |
| {PID} | ID de proceso | 2772 |
| {TIEMPO} | Tiempo en segundos desde la época. | 1299852985 |
| {PROGRAMA} | Nombre de archivo completo del ejecutable en tiempo de ejecución del programa. | C:AlgúnDondeTuUnoarchivo.exe |
| {PROGRAM_BASE} | Sin sufijo del nombre de archivo en tiempo de ejecución del ejecutable. | C:AlgúnDondeTuUnArchivo |
| {CACHE_DIR} | Directorio de caché para el usuario. | C:UsuariosSomeBodyAppDataLocal |
| {COMPAÑÍA} | Valor dado como --company-name | Nombre de su empresa |
| {PRODUCTO} | Valor dado como --product-name | Su nombre de producto |
| {VERSIÓN} | Combinación de --file-version y --product-version | 3.0.0.0-1.0.0.0 |
| {HOGAR} | Directorio de inicio del usuario. | /casa/alguien |
| {NINGUNO} | Cuando se proporciona para salidas de archivos, se utiliza None | ver aviso a continuación |
| {NULO} | Cuando se proporciona para salidas de archivos, se utiliza os.devnull | ver aviso a continuación |
Importante
Es su responsabilidad hacer que la ruta proporcionada sea única; en Windows, un programa en ejecución se bloqueará y, si bien es posible usar un nombre de carpeta fijo, puede causar problemas de bloqueo en ese caso, donde el programa se reinicia.
Por lo general, necesita usar {TIME} o al menos {PID} para hacer que una ruta sea única, y esto está destinado principalmente a casos de uso, donde, por ejemplo, desea que las cosas residan en un lugar que usted elija o respete sus convenciones de nomenclatura.
Importante
Para deshabilitar la salida y stderr con --force-stdout-spec y --force-stderr-spec los valores {NONE} y {NULL} lo logran, pero con un efecto diferente. Con {NONE} , el identificador correspondiente se convierte en None . Como resultado, por ejemplo, sys.stdout será None , que es diferente de {NULL} donde estará respaldado por un archivo que apunta a os.devnull , es decir, puedes escribir en él.
Con {NONE} , puede obtener, por ejemplo, RuntimeError: lost sys.stdout en caso de que se use; con {NULL} eso nunca sucede. Sin embargo, algunas bibliotecas manejan esto como entrada para su mecanismo de registro, y en Windows así es como es compatible con pythonw.exe , que se comporta como {NONE} .
Si tiene una creación de ruedas impulsada por setup.py , setup.cfg o pyproject.toml para su software, utilizar Nuitka es extremadamente fácil.
Comencemos con el enfoque setuptools más común. Puede, teniendo Nuitka instalado, por supuesto, simplemente ejecutar el objetivo bdist_nuitka en lugar de bdist_wheel . Toma todas las opciones y le permite especificar algunas más, que son específicas de Nuitka.
# Para setup.py si no usas otros sistemas de compilación: setup( # Los archivos de datos deben ser manejados por setuptools y no por Nuitka
package_data={"algún_paquete": ["algún_archivo.txt"]},
..., # Esto es para pasar las opciones de Nuitka.
command_options={ 'nuitka': { # opción booleana, por ejemplo, si le interesan los comandos de compilación de C '--show-scons': Verdadero, # opciones sin valor, por ejemplo, aplicar el uso de Clang '--clang': Ninguno, # opciones con valores únicos, por ejemplo, habilitar un complemento de Nuitka '--enable-plugin': "pyside2", # opciones con varios valores, por ejemplo, evitar incluir módulos '--nofollow-import-to': ["*.pruebas", "*.distutils"],
},
},
)# Para setup.py con otros sistemas de compilación:# La naturaleza tupla de los argumentos es requerida por la naturaleza oscura de# "setuptools" y sus complementos, que insisten en una compatibilidad total,# por ejemplo, "setuptools_rust"setup( # Archivos de datos deben ser manejados por setuptools y no por Nuitka
package_data={"algún_paquete": ["algún_archivo.txt"]},
..., # Esto es para pasar las opciones de Nuitka.
..., command_options={ 'nuitka': { # opción booleana, por ejemplo, si te interesan los comandos de compilación de C '--show-scons': ("setup.py", True), # opciones sin valor, por ejemplo, aplicar el uso Clang '--clang': ("setup.py", Ninguno), # opciones con valores únicos, por ejemplo, habilitar un complemento de Nuitka '--enable-plugin': ("setup.py", "pyside2"), # opciones con varios valores, por ejemplo, evite incluir módulos '--nofollow-import-to' : ("setup.py", ["*.tests", "*.distutils"]),
}
},
) Si por alguna razón no puede o no desea cambiar el objetivo, puede agregarlo a su setup.py .
# Para setup.pysetup( ..., build_with_nuitka=Verdadero)
Nota
Para deshabilitar temporalmente la compilación, puede eliminar la línea anterior o editar el valor a False o tomar su valor de una variable de entorno si así lo desea, por ejemplo, bool(os.getenv("USE_NUITKA", "True")) . Esto depende de ti.
O podrías ponerlo en tu setup.cfg
[metadatos]build_with_nuitka = verdadero
Y por último, pero no menos importante, Nuitka también admite la nueva meta build , por lo que cuando ya tenga un pyproject.toml , simplemente reemplace o agregue este valor:
[build-system]requires = ["setuptools>=42", "wheel", "nuitka", "toml"]build-backend = "nuitka.distutils.Build"# Los archivos de datos deben ser manejados por setuptools y no por Nuitka [tool.setuptools.package-data]some_package = ['data_file.txt'] [tool.nuitka]# No se recomiendan, pero hacen que sea obvio que tienen efecto.# opción booleana, por ejemplo, si le interesan los comandos de compilación de C, se omiten los # guiones inicialesshow-scons = true# opciones con valores únicos, por ejemplo, habilitar un complemento de Nuitkaenable-plugin = "pyside2"# opciones con varios valores, por ejemplo, evitar incluir módulos, acepta# lista argumento.nofollow-import-to = ["*.tests", "*.distutils"]
Nota
Para el requisito nuitka anterior a rutas absolutas como C:Users...Nuitka también funcionará en Linux, use una ruta absoluta con dos barras diagonales iniciales, por ejemplo //home/.../Nuitka .
Nota
Cualquiera sea el enfoque que adopte, los archivos de datos en estas ruedas no son manejados por Nuitka en absoluto, sino por herramientas de configuración. Sin embargo, puede utilizar el archivo de datos incorporado del comercial de Nuitka. En ese caso, en realidad debería incrustar los archivos dentro del módulo de extensión y no como un archivo en la rueda.
Si tiene varios programas, cada uno de ellos debe ser ejecutable, en el pasado tenía que compilar varias veces e implementarlos todos. Con el modo independiente, esto, por supuesto, significaba que era un desperdicio considerable, ya que se podían compartir las carpetas, pero Nuitka no lo admitía realmente.
Ingrese Multidist . Hay una opción --main que reemplaza o agrega al argumento posicional dado. Y se puede dar varias veces. Cuando se le da varias veces, Nuitka creará un binario que contiene el código de todos los programas proporcionados, pero compartiendo los módulos utilizados en ellos. Por lo tanto, no es necesario distribuirlos varias veces.
Llamemos al nombre base de la ruta principal y al punto de entrada. Por supuesto, los nombres de estos deben ser diferentes. Luego, el binario creado puede ejecutar cualquier punto de entrada y reaccionará a lo que le aparezca sys.argv[0] . Entonces, si se ejecuta de la manera correcta (con algo como subprocess o API del sistema operativo, puede controlar este nombre), o cambiando el nombre o copiando el binario, o creando un enlace simbólico a él, puede lograr el milagro.
Esto permite combinar programas muy diferentes en uno.
Nota
Esta característica aún es experimental. Úselo con cuidado e informe sus hallazgos si encuentra algo que sea un comportamiento indeseable.
Este modo funciona de forma independiente, con un solo archivo y con simple aceleración. No funciona con el modo módulo.
Para la integración con los flujos de trabajo de GitHub, existe esta Nuitka-Action que debes usar y que hace que la integración sea realmente fácil. Deberías comenzar con una compilación local, pero será más fácil para la compilación multiplataforma con Nuitka.
Este es un flujo de trabajo de ejemplo que se basa en los 3 sistemas operativos.
trabajos:compilación: estrategia: matriz: sistema operativo: [macos-último, ubuntu-último, windows-último]
continúa: ${{ Matrix.os }}
pasos:
- nombre: usos del repositorio de check-out: acciones/checkout@v4 - nombre: usos de configuración de Python: acciones/setup-python@v5 con: versión-python: '3.10' caché: 'pip' ruta-dependencia-caché: | **/requirements*.txt - nombre: Instale sus Dependencias ejecute: | pip install -r requisitos.txt -r requisitos-dev.txt - nombre: Build Executable with Nuitka usa: Nuitka/Nuitka-Action@main con: nuitka-version: main script-name: your_main_program.py # muchas más opciones de Nuitka disponibles , consulte el documento de acción, pero es mejor # usar las opciones nuitka-project: en su código, de modo que, por ejemplo, pueda marcar # una diferencia para macOS y crear un paquete de aplicaciones allí. onefile: true - nombre: Upload Artifacts utiliza: acciones/upload-artifact@v3 con: nombre: ${{ runner.os }} Ruta de compilación: | # coincide con lo creado para los 3 sistemas operativos build/*.exe build/*.bin build/*.app/**/* Si su aplicación es una GUI, por ejemplo, your_main_program.py debe contener estos comentarios como se explica en Opciones de Nuitka en el código, ya que en macOS esto debería ser un paquete.
# Modo de compilación, independiente en todas partes, excepto en macOS, hay un paquete de aplicaciones# 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#Para una buena apariencia, puede especificar íconos. En Windows, puede proporcionar un archivo de icono, una plantilla ejecutable o un archivo PNG. Todos estos funcionarán e incluso pueden combinarse:
# Estos crean archivos binarios con íconos en Windowspython -m nuitka --onefile --windows-icon-from-ico=your-icon.png program.py python -m nuitka --onefile --windows-icon-from-ico=tu-icon.ico program.py python -m nuitka --onefile --windows-icon-template-exe=your-icon.ico program.py# Estos crean paquetes de aplicaciones con íconos en macOSpython -m nuitka --macos-create-app-bundle --macos- icono-aplicación=tu-icono.png programa.py python -m nuitka --macos-create-app-bundle --macos-app-icon=tu-icono.icns program.py
Nota
Con Nuitka, no es necesario crear iconos específicos de la plataforma, sino que convertirá, por ejemplo, PNG, pero también otros formatos sobre la marcha durante la construcción.
Se pueden agregar derechos para un paquete de aplicaciones macOS con la opción --macos-app-protected-resource , todos los valores se enumeran en esta página de Apple
Un valor de ejemplo sería --macos-app-protected-resource=NSMicrophoneUsageDescription:Microphone access para solicitar acceso a un micrófono. Después de los dos puntos, se debe proporcionar el texto descriptivo.
Nota
Tenga en cuenta que en el caso probable de utilizar espacios en la parte de descripción, deberá citarlos para que su shell llegue a Nuitka y no se interprete como argumentos de Nuitka.
En Windows, los programas no abren la consola a menos que usted lo indique. Nuitka no lo muestra de forma predeterminada, aunque puedes forzarlo usando --console=force , luego el programa abrirá una nueva ventana de terminal cuando se ejecute.
Las pantallas de presentación son útiles cuando el inicio del programa es lento. El inicio de Onefile en sí no es lento, pero su programa puede serlo y no puede saber realmente qué tan rápida será la computadora utilizada, por lo que podría ser una buena idea tenerlos. Afortunadamente, con Nuitka, son fáciles de agregar para Windows.
Para la pantalla de presentación, debe especificarla como un archivo PNG y luego asegurarse de desactivar la pantalla de presentación cuando su programa esté listo, por ejemplo, haya completado las importaciones, haya preparado la ventana, se haya conectado a la base de datos y desee la pantalla de presentación. para irse. Aquí estamos usando la sintaxis del proyecto para combinar el código con la creación, compila esto:
# nuitka-project: --onefile# nuitka-project: --onefile-windows-splash-screen-image={MAIN_DIRECTORY}/Splash-Screen.png# Sea lo que sea, obviamenteprint("Retrasando el inicio por 10 segundos..." )importar tiempo, archivo temporal, ostime.sleep(10)# Utilice este código para indicar la eliminación de la pantalla de presentación.if "NUITKA_ONEFILE_PARENT" en os.environ: splash_filename = os.path.join( tempfile.gettempdir(), "onefile_%d_splash_feedback.tmp" % int(os.environ["NUITKA_ONEFILE_PARENT"]),
) si os.path.exists(splash_filename): os.unlink(splash_filename)print("Listo... el splash debería desaparecer.")
...# El resto de tu programa va aquí.Para el análisis de su programa y del empaquetado de Nuitka, está disponible el Informe de compilación. También puede crear informes personalizados proporcionando su plantilla, algunas de las cuales están integradas en Nuitka. Estos informes contienen toda la información detallada, por ejemplo, cuando se intentó importar un módulo pero no se encontró, puede ver dónde sucede. Para informar errores, se recomienda proporcionar el informe.
Puede adjuntar información de derechos de autor y marcas comerciales, nombre de la empresa, nombre del producto, etc. a su compilación. Luego, esto se utiliza en la información de la versión del binario creado en Windows o en el paquete de aplicaciones en macOS. Si encuentra algo que falta, háganoslo saber.
De forma predeterminada, Nuitka se compila sin --deployment , lo que deja activado un conjunto de protecciones y ayudas destinadas a depurar usos incorrectos de Nuitka.
Esta es una característica nueva e implementa una serie de protecciones y ayudas que se documentan aquí.
Entonces, después de la compilación, sys.executable es el binario compilado. En el caso de paquetes como multiprocessing , joblib o loky -c command lo que típicamente hacen -m module_name esperar ejecutar desde una python completa con sys.executable Inicie otro código temporal o permanentemente como un demonio de servicio.
Sin embargo, con Nuitka, esto vuelve a ejecutar su programa y pone estos argumentos, en sys.argv donde tal vez los ignoras, y luego vuelves a bucear para lanzar a Helper Daemons. A veces, esto termina generando procesos de conteo de CPU que generan procesos de conteo de CPU que ... esto se llama bomba de bifurcación, y con casi todos los sistemas, eso los congela fácilmente hasta la muerte.
Es por eso que esto sucede con Nuitka predeterminado:
./hello.dist/hello.bin -l Fool -m foom -n foon -o fooo -p Error, el programa intentó llamarse a sí mismo con el argumento '-M'. Deshabilitar con '--No-Deployment-Flag = Auto-Ejecución'.
Su programa puede tener su propio análisis de línea de comandos y no usar un paquete no compatible que intente volver a ejecutar. En este caso, necesita en el momento de la compilación para usar --no-deployment-flag=self-execution que deshabilita a este guardia específico.
Algunos paquetes generan lo que creen que es información útil sobre lo que podría significar la razón de una importación fallida. Con los programas compilados, muy a menudo es simplemente incorrecto. Intentamos repararlos en modo de no desplegar. Aquí hay un ejemplo, en el que cambiamos un mensaje que le pide instalar PIP (que no es el problema) para apuntar al usuario al comando incluir que hace que un complemento imageio funcione.
- Nombre del módulo: 'imageio.core.imopen'
Anti-Blata:
-reemplazos_plain: '`pip install imageio [{config.install_name}]` instalarlo': '`--include-module = {config.module_name}` con nuitka para incluir it''err_type = importerRor': 'err_type = = RuntimeError 'cuándo:' no implementación ' El modo de implementación es relativamente nuevo y tiene constantemente más funciones agregadas, por ejemplo, algo para FileNotFoundError debería llegar pronto.
Por supuesto, todos estos ayudantes pueden desactivarse a la vez con --deployment pero tenga en cuenta que para la depuración, es posible que desee volver a habilitarlo. Es posible que desee utilizar las opciones de proyecto Nuitka y una variable de entorno para hacer esto condicional.
¿Deberías deshabilitarlos a todos?
Creemos que deshabilitar solo debe ocurrir selectivamente, pero con las actualizaciones de PYPI, su código cambia, todos estos problemas pueden volver a colocar. El ahorro de espacio del modo de implementación es actualmente insignificante, así que intente no hacerlo, pero revise lo que existe, y Si sabe que no puede afectarlo, o si lo hace, no lo necesitará. Algunos de los futuros, claramente estarán orientados al uso de nivel para principiantes.
Los binarios compilados en Windows con configuración predeterminada de Nuitka y no hay más acciones tomadas por algunos proveedores AV como malware. Esto es evitable, pero solo en el comercial de Nuitka hay apoyo e instrucciones reales sobre cómo hacerlo, viendo esto como una necesidad comercial típica. https://nuitka.net/doc/commercial.html
Para Linux Standalone es bastante difícil construir un binario que funcione en otras versiones de Linux. Esto se debe principalmente a que en Linux, mucho software se crea específicamente dirigido a DLL concretos. Cosas como GLIBC utilizadas se codifican en el binario construido, y no se ejecutará con un GLIBC más antiguo, solo para dar un ejemplo crítico.
La solución es construir sobre el sistema operativo más antiguo que desea ver compatible. Elegir eso y configurarlo puede ser tedioso, por lo que puede ser inicio de sesión y mantenerlo
