NUITKA-RUN(1)

📦
version 1.3.5 · 2 versions
, in ubuntu noble, ubuntu resolute

🌸 NUITKA-RUN(1) — the Python compiler 🌸

Okay bestie, welcome to the manual for nuitka-run — yes, it's the Python compiler, and it's lowkey iconic 💅

💖 NAME 💖

nuitka-run — the Python compiler

✨ SYNOPSIS ✨

nuitka-run [options] main_module.py

👑 OPTIONS 👑

Here's the whole menu of flags, no cap. Every single one, we're not skipping a thing 💅

  • --help — shows you this exact help message and then bounces. That's it.
  • --version — spills the version info plus all the important deets for bug reports, then exits. Defaults to off.
  • --module — makes an extension module executable instead of a regular program. Defaults to off.
  • --standalone — turns on standalone mode for the output. This means you can yeet the created binary to other machines and it won't need an existing Python installation. It also means the thing gets big. It implies these options: -- follow-imports and --python-flag=no_site. Defaults to off.
  • --onefile — on top of standalone mode, turns on onefile mode. So instead of a folder, you get a compressed executable that's created and used. Defaults to off.
  • --python-debug — use the debug version or not. The default is whatever you're using to run Nuitka, which is most likely a non-debug version.
  • --python-flag=FLAG — Python flags to use. The default is whatever you're using to run Nuitka — this forces a specific mode. These are options that also exist for the standard Python executable. Currently supported: -S (alias no_site), static_hashes (do not use hash randomization), no_warnings (do not give Python run time warnings), -O (alias no_asserts), no_docstrings (do not use doc strings), -u (alias unbuffered) and -m. Default empty.
  • --python-for-scons=PATH — if you're on Python3.3 or Python3.4, give the path of a Python binary to use for Scons. Otherwise Nuitka can use whatever you run Nuitka with, or a Python installation from the Windows registry. On Windows you need Python 3.5 or higher. On non-Windows, Python 2.6 or 2.7 will do as well.

🎀 Control the inclusion of modules and packages in result 🎀

  • --include-package=PACKAGE — includes a whole package. Give it as a Python namespace, e.g. some_package.sub_package, and Nuitka will find it, include it, and pull in all the modules under that disk location into the binary or extension module it makes, making them available for import by the code. To avoid unwanted sub packages, like tests, you can do e.g. --nofollow-import-to=*.tests. Default empty.
  • --include-module=MODULE — includes a single module. Give it as a Python namespace, e.g. some_package.some_module, and Nuitka will find it and include it in the binary or extension module it makes, making it available for import by the code. Default empty.
  • --include-plugin-directory=MODULE/PACKAGE — also includes the code found in that directory, treating each as if it were given as a main file. Overrides all other inclusion options. You really ought to prefer other inclusion options that go by names rather than filenames — those find things by being in sys.path. This option is for very special use cases only. Can be given multiple times. Default empty.
  • --include-plugin-files=PATTERN — include into files matching the PATTERN. Overrides all other follow options. Can be given multiple times. Default empty.
  • --prefer-source-code — for already compiled extension modules where there's both a source file and an extension module, normally the extension module gets used, but it's better to compile from the available source code for best performance. If you don't want that, there's --noprefer-source-code to disable warnings about it. Default off.

🦋 Control the following into imported modules 🦋

  • --follow-imports — descends into all imported modules. Defaults to on in standalone mode, otherwise off.
  • --follow-import-to=MODULE/PACKAGE — follows to that module if used, or if it's a package, to the whole package. Can be given multiple times. Default empty.
  • --nofollow-import-to=MODULE/PACKAGE — does not follow to that module name even if it's used, or if it's a package name, to the whole package in any case — this overrides all other options. Can be given multiple times. Default empty.
  • --nofollow-imports — does not descend into any imported modules at all. Overrides all other inclusion options and isn't usable for standalone mode. Defaults to off.
  • --follow-stdlib — also descends into imported modules from the standard library. This will increase compilation time by a lot, and it's also not well tested at this time and sometimes won't work. Defaults to off.

🌈 Onefile options 🌈

  • --onefile-tempdir-spec=ONEFILE_TEMPDIR_SPEC — use this as the folder to unpack to in onefile mode. Defaults to '%TEMP%/onefile_%PID%_%TIME%', i.e. the user temporary directory, and since it's non-static it gets removed. You could use e.g. a string like '%CACHE_DIR%/%COMPANY%/%PRODUCT%/%VERSION%' which is a good static cache path — that one will then not be removed.

🍓 Data files 🍓

  • --include-package-data=PACKAGE — includes data files for the given package name. DLLs and extension modules are not data files and are never included like this. You can use patterns for the filenames as indicated below. Data files of packages are not included by default, but package configuration can do it. This will only include non-DLL, non-extension modules, i.e. actual data files. After a :, you can optionally give a filename pattern too, selecting only matching files. Examples: "--includepackage-data=package_name" (all files), "--includepackage-data=package_name=*.txt" (only certain type), " --include-package-data=package_name=some_filename.dat (concrete file). Default empty.
  • --include-data-files=DESC — includes data files by filenames in the distribution. There are many allowed forms. With '--include-datafiles=/path/to/file/*.txt=folder_name/some.txt' it will copy a single file and complain if it's multiple. With '--include-datafiles=/path/to/files/*.txt=folder_name/' it will put all matching files into that folder. For recursive copy there's a form with 3 values, '--includedata-files=/path/to/scan=folder_name=**/*.txt', that will preserve directory structure. Default empty.
  • --include-data-dir=DIRECTORY — includes data files from a complete directory in the distribution. This is recursive. Check '--includedata-files' with patterns if you want non-recursive inclusion. An example would be '--include-datadir=/path/some_dir=data/some_dir' for a plain copy of the whole directory. All files are copied; if you want to exclude files you need to remove them beforehand, or use the '--noinclude-data-files' option to remove them. Default empty.
  • --noinclude-data-files=PATTERN — do not include data files matching the filename pattern given. This is against the target filename, not source paths. So to ignore a file pattern from package data for "package_name", it should be matched as "package_name/*.txt". Or for the whole directory, simply use "package_name". Default empty.

🧚 DLL files 🧚

  • --noinclude-dlls=PATTERN — do not include DLL files matching the filename pattern given. This is against the target filename, not source paths. So to ignore a DLL "someDLL" contained in the package "package_name", it should be matched as "package_name/someDLL.*". Default empty.
  • --list-package-dlls=LIST_PACKAGE_DLLS — outputs the DLLs found for a given package name. Default not done.

💜 Control the warnings to be given by Nuitka 💜

  • --warn-implicit-exceptions — enables warnings for implicit exceptions detected at compile time.
  • --warn-unusual-code — enables warnings for unusual code detected at compile time.
  • --assume-yes-for-downloads — lets Nuitka download external code if necessary, e.g. dependency walker, ccache, and even gcc on Windows. To disable, redirect input from the nul device, e.g. "</dev/null" or "<NUL:". Default is to prompt.
  • --nowarn-mnemonic=MNEMONIC — disables warning for a given mnemonic. These are given to make sure you're aware of certain topics, and typically point to the Nuitka website. The mnemonic is the part of the URL at the end, without the HTML suffix. Can be given multiple times and accepts shell pattern. Default empty.

⭐ Immediate execution after compilation ⭐

  • --run — executes the created binary immediately (or imports the compiled module). Defaults to on.
  • --debugger — executes inside a debugger, e.g. "gdb" or "lldb", to automatically get a stack trace. Defaults to off.
  • --execute-with-pythonpath — when immediately executing the created binary or module using '--run', don't reset the 'PYTHONPATH' environment. When all modules are successfully included, you ought to not need PYTHONPATH anymore, and definitely not for standalone mode.

🫶 Compilation choices 🫶

  • --user-package-configuration-file=YAML_FILENAME — a user-provided Yaml file with package configuration. You can include DLLs, remove bloat, add hidden dependencies. Check the User Manual for a complete description of the format to use. Can be given multiple times. Defaults to empty.
  • --full-compat — enforces absolute compatibility with CPython. Do not even allow minor deviations from CPython behavior, e.g. not having better tracebacks or exception messages which are not really incompatible, but only different or worse. This is intended for tests only and should not be used.
  • --file-reference-choice=MODE — selects what value "__file__" is going to be. With "runtime" (default for standalone binary mode and module mode), the created binaries and modules use the location of themselves to deduce the value of "__file__". Included packages pretend to be in directories below that location. This allows you to include data files in deployments. If you merely seek acceleration, it's better to use the "original" value, where the source file's location is used. With "frozen", a notation "<frozen module_name>" is used. For compatibility reasons, the "__file__" value will always have a ".py" suffix independent of what it really is.
  • --module-name-choice=MODE — this is the one that decides what __name__ and __package__ are gonna be, and honestly it's giving ✨ identity crisis ✨ energy. With "runtime" (which is the default for module mode), the created module uses the parent package to figure out __package__, so it's fully compatible. The value "original" (the default for other modes) lets more static optimization happen, but it's incompatible for modules that normally can be loaded into any package. pick your fighter 💅

💾 Output choices 💾

  • --output-filename=FILENAME — tells Nuitka how the executable should be named. For extension modules there is no choice, and also not for standalone mode — using it there is an error bestie. You can include path info in it, but that path needs to already exist tho. Defaults to '<program_name>' on this platform. .bin 🫶
  • --output-dir=DIRECTORY — where the intermediate and final output files get dumped. That DIRECTORY is gonna get filled with the build folder, dist folder, binaries, etc. Defaults to the current directory. 🌸
  • --remove-output — nukes the build directory after it's done producing the module or exe file. Defaults to off. 🗑️
  • --no-pyi-file — do not create a .pyi file for extension modules made by Nuitka. This file is what's used to detect implicit imports. Defaults to off. 🎀

🐛 Debug features 🐛

  • --debug — runs all the self checks possible to hunt down errors in Nuitka. Do not use for production. Defaults to off. (devs only, iykyk 💀)
  • --unstripped — keeps debug info in the resulting object file so your debugger interaction is nicer. Defaults to off. 🔍
  • --profile — enables vmprof based profiling of time spent. Not working currently. Defaults to off. 😭
  • --internal-graph — creates a graph of the optimization process internals. Do not use for whole programs, only for small test cases. Defaults to off. 📊
  • --trace-execution — traced execution output: it prints the line of code before executing it. Defaults to off. 👀
  • --recompile-c-only — this is not incremental compilation, it's for Nuitka development only, periodt. It takes existing files and simply compiles them as C again. It lets you compile edited C files for quick debugging changes to the generated source — e.g. to see if code is passed by, values output, etc. Defaults to off. Depends on compiling Python source to determine which files it should look at. 🧪
  • --xml=XML_FILENAME — writes the internal program structure and the result of optimization in XML form to the given filename. 📝
  • --generate-c-only — generates only C source code, and does not compile it to binary or module. This is for debugging and code coverage analysis that doesn't waste CPU. Defaults to off. Do not think you can use this directly. 🙈
  • --experimental=FLAG — uses features declared as 'experimental'. May have no effect if no experimental features are present in the code. Uses secret tags (check source) per experimented feature. 🔬
  • --low-memory — tries to use less memory by forking fewer C compilation jobs and using options that use less memory. For use on embedded machines. Use this if you're hitting out of memory problems. Defaults to off. 🧠

🔧 Backend C compiler choice 🔧

  • --clang — forces the use of clang. On Windows this requires a working Visual Studio version to piggy back on. Defaults to off. 🦋
  • --mingw64 — forces the use of MinGW64 on Windows. Defaults to off unless MSYS2 with MinGW Python is used. 🪟
  • --msvc=MSVC_VERSION — forces the use of a specific MSVC version on Windows. Allowed values are e.g. "14.3" (MSVC 2022) and other MSVC version numbers — or specify "list" for a list of installed compilers, or use "latest". Defaults to latest MSVC being used if installed, otherwise MinGW64 is used. 👑
  • --jobs=N — sets the allowed number of parallel C compiler jobs. Defaults to the system CPU count. ⚡
  • --lto=choice — use link time optimizations (MSVC, gcc, clang). Allowed values are "yes", "no", and "auto" (when it's known to work). Defaults to "auto". 🔥
  • --static-libpython=choice — use the static link library of Python. Allowed values are "yes", "no", and "auto" (when it's known to work). Defaults to "auto". 🐍

🗂️ Cache Control 🗂️

  • --disable-cache=DISABLED_CACHES — disables selected caches, specify "all" for all cached. Currently allowed values are: "all","ccache","bytecode". Can be given multiple times or with comma separated values. Default none. 🚫
  • --clean-cache=CLEAN_CACHES — cleans the given caches before executing, specify "all" for all cached. Currently allowed values are: "all","ccache","bytecode". Can be given multiple times or with comma separated values. Default none. 🧼
  • --disable-bytecode-cache — do not reuse dependency analysis results for modules — esp. from the standard library — that are included as bytecode. Same as --disable-cache=bytecode. 🧊
  • --disable-ccache — do not attempt to use ccache (gcc, clang, etc.) or clcache (MSVC, clangcl). Same as --disablecache=ccache. 🚫

📈 PGO compilation choices 📈

  • --pgo — enables C level profile guided optimization (PGO) by executing a dedicated build first for a profiling run, and then using the result to feedback into the C compilation. Note: this is experimental and not working with standalone modes of Nuitka yet. Defaults to off. 🔬
  • --pgo-args=PGO_ARGS — arguments to be passed in case of profile guided optimization. These get passed to the special built executable during the PGO profiling run. Default empty. 📨
  • --pgo-executable=PGO_EXECUTABLE — the command to execute when collecting profile information. Use this only if you need to launch it through a script that prepares it to run. Default: use the created program. 🏃‍♀️

🔎 Tracing features 🔎

  • --report=REPORT_FILENAME — reports module, data files, compilation, plugin, etc. details in an XML output file. This is also super useful for issue reporting. Default is off. 🐞
  • --quiet — disables all information outputs, but still shows warnings. Defaults to off. 🤫
  • --show-scons — runs the C building backend Scons with verbose information, showing the executed commands and detected compilers. Defaults to off. 🛠️
  • --no-progressbar — disables progress bars. Defaults to off. 📉
  • --show-progress — Obsolete: provide progress information and statistics. Disables the normal progress bar. Defaults to off. 💀
  • --show-memory — provides memory information and statistics. Defaults to off. 🧠
  • --show-modules — provides information for included modules and DLLs. Obsolete: you should use the '--report' file instead. Defaults to off. 📦
  • --show-modules-output=PATH — where to output '--show-modules'; should be a filename. Default is standard output. 📤
  • --verbose — outputs details of actions taken, esp. in optimizations. Can become a lot. Defaults to off. 🗣️
  • --verbose-output=PATH — where to output from '--verbose'; should be a filename. Default is standard output. 📥

🖥️ General OS controls 🖥️

  • --disable-console — when compiling for Windows or macOS, disables the console window and creates a GUI application. Defaults to off. 🪟
  • --enable-console — when compiling for Windows or macOS, enables the console window and creates a console application. This disables hints from certain modules, e.g. "PySide", that suggest to disable it. Defaults to true. ✅
  • --force-stdout-spec=FORCE_STDOUT_SPEC — forces standard output of the program to go to this location. Useful for programs with a disabled console and programs using the Windows Services Plugin of Nuitka commercial. Defaults to not active — use e.g. '%PROGRAM%.out.txt', i.e. a file near your program. 📄
  • --force-stderr-spec=FORCE_STDERR_SPEC — forces standard error of the program to go to this location. Useful for programs with a disabled console and programs using the Windows Services Plugin of Nuitka commercial. Defaults to not active — use e.g. '%PROGRAM%.err.txt', i.e. a file near your program. 📄

🪟 Windows specific controls 🪟

  • --windows-icon-from-ico=ICON_PATH — adds an executable icon. Can be given multiple times for different resolutions or files with multiple icons inside. In the latter case, you may also suffix with #<n> where n is an integer index starting from 1, specifying a specific icon to be included, and all others to be ignored. 🎨
  • --windows-icon-from-exe=ICON_EXE_PATH — copies executable icons from this existing executable (Windows only). 👯
  • --onefile-windows-splash-screen-image=SPLASH_SCREEN_IMAGE — when compiling for Windows and onefile, shows this while loading the application. Defaults to off. 🖼️
  • --windows-uac-admin — requests Windows User Control to grant admin rights on execution. (Windows only). Defaults to off. 👮
  • --windows-uac-uiaccess — requests Windows User Control to enforce running from a few folders only, and remote desktop access. (Windows only). Defaults to off. 🔐

🍎 macOS specific controls 🍎

  • --macos-target-arch=MACOS_TARGET_ARCH — what architectures this is supposed to run on. Default and limit is what the running Python allows for. Default is "native", which is the architecture the Python is run with. 🏗️
  • --macos-create-app-bundle — when compiling for macOS, creates a bundle rather than a plain binary application. Currently experimental and incomplete. Currently this is the only way to unlock disabling of console. Defaults to off. 📦
  • --macos-app-icon=ICON_PATH — adds an icon for the application bundle to use. Can be given only one time. Defaults to the Python icon if available. 🎀
  • --macos-signed-app-name=MACOS_SIGNED_APP_NAME — name of the application to use for macOS signing. Follow "com.YourCompany.AppName" naming for best results, as these have to be globally unique, and will potentially grant protected API accesses. ✍️
  • --macos-app-name=MACOS_APP_NAME — name of the product to use in macOS bundle information. Defaults to the base filename of the binary. 💖
  • --macos-app-mode=MODE — bestie, this is the whole vibe of your app bundle. When you're launching a Window and you want it showing up in Docker (yes, literally "Docker", that's what it says 💀), the default value "gui" is your girl. If your app never opens a Window at all, it's a "background" application. And for UI elements that only get to show up later? "ui-element" is the in-between queen — she won't appear in the dock, but she gets full access to the desktop the moment she does open a Window later. 👑
  • --macos-sign-identity=MACOS_APP_VERSION — so when you sign on macOS, by default an ad-hoc identity gets used, but with this option you get to specify a whole other identity to use. Signing code is mandatory on macOS now and it cannot be disabled, periodt. Default is "ad-hoc" if you don't give anything. 🔏
  • --macos-sign-notarization — when you're signing for notarization using a proper TeamID identity from Apple, flip this on so the required runtime signing option gets used, meaning it can actually be accepted. 🍎
  • --macos-app-version=MACOS_APP_VERSION — the product version that goes into your macOS bundle information. Defaults to "1.0" if you don't say otherwise. ✨
  • --macos-app-protected-resource=RESOURCE_DESC — this one requests an entitlement for access to a macOS protected resource. Like, e.g. "NSMicrophoneUsageDescription:Microphone access for recording audio." asks for microphone access and gives the user an informative little text about why on earth that's needed. Before the colon you put an OS identifier for the access right, then the informative text after it. You can find legal values at https://developer.apple.com/documentation/bundleresources/information_property_list/protected_resources and you can specify this option multiple times. Default is empty. 🎤

🐧 Linux specific controls 🐧

  • --linux-icon=ICON_PATH — adds an executable icon for the onefile binary to use. Can be given only one time, so don't get greedy. Defaults to the Python icon if it's available. 🖼️

📦 Binary Version Information 📦

  • --company-name=COMPANY_NAME — the name of the company used in version information. Defaults to unused.
  • --product-name=PRODUCT_NAME — the name of the product used in version information. Defaults to the base filename of the binary.
  • --file-version=FILE_VERSION — the file version used in version information. It must be a sequence of up to 4 numbers, e.g. 1.0 or 1.0.0.0 — no more digits allowed, no strings allowed, no exceptions bestie. Defaults to unused. ⚠️
  • --product-version=PRODUCT_VERSION — the product version used in version information. Same rules as for file version, so don't try anything cute. Defaults to unused.
  • --file-description=FILE_DESCRIPTION — a description of the file used in version information. Windows only at this time. Defaults to the binary filename.
  • --copyright=COPYRIGHT_TEXT — copyright used in version information. Windows only at this time. Defaults to not present.
  • --trademarks=TRADEMARK_TEXT — copyright used in version information. Windows only at this time. Defaults to not present.

🔌 Plugin control 🔌

  • --enable-plugin=PLUGIN_NAME — enabled plugins. Must be plug-in names. Use --pluginlist to query the full list and exit. Default empty.
  • --disable-plugin=PLUGIN_NAME — disabled plugins. Must be plug-in names. Use -- plugin-list to query the full list and exit. Most standard plugins are not a good idea to disable, so like, be careful. Default empty.
  • --plugin-no-detection — plugins can detect if they might be used, and then you can disable the warning via --disable-plugin=pluginthat-warned, or you can use this option to disable the mechanism entirely. Which also speeds up compilation slightly, of course, because that detection code is running in vain once you're already certain which plugins you want. Defaults to off.
  • --plugin-list — show the list of all available plugins and exit. Defaults to off.
  • --user-plugin=PATH — the file name of a user plugin. Can be given multiple times. Default empty.
  • --show-source-changes — show source changes to the original Python file content before compilation. Mostly intended for developing plugins. Default False.

🎈 Plugin options of 'anti-bloat' 🎈

  • --show-anti-bloat-changes — annotate what changes are done by the plugin.
  • --noinclude-setuptools-mode=NOINCLUDE_SETUPTOOLS_MODE — what to do if a 'setuptools' import is encountered. This package can be big with dependencies, and should definitely be avoided. Also handles 'setuptools_scm'.
  • --noinclude-pytest-mode=NOINCLUDE_PYTEST_MODE — what to do if a 'pytest' import is encountered. This package can be big with dependencies, and should definitely be avoided. Also handles 'nose' imports.
  • --noinclude-unittest-mode=NOINCLUDE_UNITTEST_MODE — what to do if a unittest import is encountered. This package can be big with dependencies, and should definitely be avoided.
  • --noinclude-IPython-mode=NOINCLUDE_IPYTHON_MODE — what to do if an IPython import is encountered. This package can be big with dependencies, and should definitely be avoided.
  • --noinclude-dask-mode=NOINCLUDE_DASK_MODE — what to do if a 'dask' import is encountered. This package can be big with dependencies, and should definitely be avoided.
  • --noinclude-numba-mode=NOINCLUDE_NUMBA_MODE — what to do if a 'numba' import is encountered. This package can be big with dependencies, and it's currently not working for standalone. Should definitely be avoided, fr fr.
  • --noinclude-default-mode=NOINCLUDE_DEFAULT_MODE — this actually provides the default "warning" value for the above options, and can be used to turn all of them on.
  • --noinclude-custom-mode=CUSTOM_CHOICES — what to do if a specific import is encountered. The format is a module name, which can and should be a top level package, and then one choice: "error", "warning", "nofollow", e.g. PyQt5:error.

And here's the little system mood board it prints out, kept exactly as it comes 💅:

Commercial: None Python: 3.9.2 (default, Feb 28 2021, 17:03:44) Flavor:
Debian Python Executable: /usr/bin/python3 OS: Linux Arch: x86_64
Distribution: Debian 11 Version C compiler: /usr/lib/ccache/gcc (gcc).

✨ EXAMPLES ✨

Compile a Python file "some_module.py" to a module "some_module.so":

$ nuitka --module some_module.py

Compile a Python program "some_program.py" to an executable "some_program.exe":

$ nuitka some_program.py

Compile a Python program "some_program.py" and the package "some_package" it uses to an executable "some_program.exe":

$ nuitka --follow-import--to=some_package some_program.py

Compile a Python program "some_program.py" and all the modules it uses to an executable "some_program.exe". Then execute it immediately when ready:

$ nuitka --run --follow-imports some_program.py

Compile a Python program "some_program.py" and the modules it uses (even standard library) to an executable "some_program.exe":

$ nuitka --recurse-all --follow-stdlib some_program.py

Compile a Python program "some_program.py" and the modules it uses to an executable "some_program.exe". Keep the debug information, so valgrind, gdb, etc. work nicely.

Note: This will not degrade performance:
$ nuitka --unstripped --follow-imports some_program.py

Compile a Python program "some_program.py" and the modules it uses to an executable "some_program.exe". Perform all kinds of checks about correctness of the generated C and run-time checks.

Note: This will degrade performance and should only be used to debug Nuitka:
$ nuitka --debug --follow-imports some_program.py

Compile a Python program "some_program.py" and the modules it uses to an executable "some_program.exe". Perform all kinds of checks about correctness of the generated C and run-time checks. Also use the debug Python library, which does its own checks.

Note: This will degrade performance and should only be used to debug Nuitka:
$ nuitka --debug --python-debug --follow-imports some_program.py

and that's the whole page bestie, you made it to the end 🎀🫶

This one's for nuitka-run version 1.3.5, dated January 2023 — so if you're reading this in a different era, go check NUITKA-RUN(1) for the current tea. 💖✨

📦 where this page comes from