之前使用 pyinstaller 打包 flet 应用,但对于 Linux 下收集到的库文件有些缺失,如openssl, sweat等。最后选择转到nuitka进行打包。
nuitka 参数为
用法:__main__.py [--module] [--run] [选项] main_module.py 选项: --help 显示此帮助消息并退出 --version 显示版本信息和有关错误报告的重要详细信息,然后退出。默认为关闭。 --module 创建扩展模块可执行文件而不是程序。默认为关闭。 --standalone 启用输出的独立模式。这使您可以在不使用现有Python安装的情况下将创建的二进制文件传输到其他计算机。这也意味着它会变得很大。它暗示这些选项:“--follow-imports”和“--python-flag=no_site”。默认为关闭。 --onefile 在独立模式之上,启用onefile模式。这意味着不是一个文件夹,而是创建并使用压缩的可执行文件。默认为关闭。 --python-debug 是否使用调试版本。默认使用运行Nuitka的版本,最可能是非调试版本。 --python-flag=FLAG 要使用的Python标志。默认为运行Nuitka的版本,这强制执行特定模式。这些是标准Python可执行文件中也存在的选项。当前支持的选项:“-S”(别名“no_site”),“static_hashes”(不使用哈希随机化),“no_warnings”(不提供Python运行时警告),“-O”(别名“no_asserts”),“no_docstrings”(不使用文档字符串),“-u”(别名“unbuffered”)和“-m”。默认为空。 --python-for-scons=PATH 如果使用Python3.3或Python3.4,请提供要用于Scons的Python二进制文件的路径。否则,Nuitka可以使用您运行Nuitka的内容或Windows注册表中的Python安装。在Windows上,需要Python 3.5或更高版本。在非Windows上,Python 2.6或2.7也可以。 控制结果中模块和软件包的包含: --include-package=PACKAGE 包含整个软件包。给出Python名称空间,例如“some_package.sub_package”,然后Nuitka将找到它并将其包含在创建的二进制文件或扩展模块中,并使其可供代码导入。为避免不需要的子软件包,例如测试,您可以执行此操作“--nofollow-import-to=*.tests”。默认为空。 --include-module=MODULE 包含单个模块。给出Python名称空间,例如“some_package.some_module”,然后Nuitka将找到它并将其包含在创建的二进制文件或扩展模块中,并使其可供代码导入。默认为空。 --include-plugin-directory=MODULE/PACKAGE 还包括在该目录中找到的代码,视为每个给定的主文件。覆盖所有其他包含选项。您应该首选其他按名称而不是按文件名的包含选项,这些选项通过在“sys.path”中查找内容。此选项仅用于非常特殊的用例。可以多次给出。默认为空。 --include-plugin-files=PATTERN 包括与PATTERN匹配的文件。覆盖所有其他关注选项。可以多次给出。默认为空。 --prefer-source-code 对于已编译的扩展模块,其中存在源文件和扩展模块,通常使用扩展模块,但最好从可用的源代码编译模块以获得最佳性能。如果不需要,有“--no-prefer-source-code”以禁用有关它的警告。默认为关闭。 控制导入模块中以下内容: --follow-imports 进入所有导入的模块。默认为独立模式下开启,否则关闭。 --follow-import-to=MODULE/PACKAGE 如果使用,则跟随该模块,或者如果是包,则跟随整个包。可以多次给出。默认为空。 --nofollow-import-to=MODULE/PACKAGE 不要跟随该模块名称,即使使用,或者如果是包名称,则在任何情况下也不要跟随整个包,覆盖所有其他选项。可以多次给出。默认为空。 --nofollow-imports 不要进入任何导入的模块,覆盖所有其他包含选项,并且不能用于独立模式。默认为关闭。 --follow-stdlib 还可以进入来自标准库的导入模块。这将大大增加编译时间,目前也没有得到很好的测试,并且有时不起作用。默认为关闭。 Onefile选项: --onefile-tempdir-spec=ONEFILE_TEMPDIR_SPEC 在onefile模式下使用此文件夹进行解压缩。默认为“%TEMP%/onefile_%PID%_%TIME%”,即用户临时目录并且是非静态的,它将被删除。例如使用一个字符串“%CACHE_DIR%/%COMPANY%/%PRODUCT%/%VERSION%”,这是一个很好的静态缓存路径,然后不会被删除。 --onefile-child-grace-time=GRACE_TIME_MS 当停止子进程时,例如由于CTRL-C或关闭等,Python代码会得到“KeyboardInterrupt”,它可以处理它以刷新数据。这是在以硬方式杀死子进程之前的毫秒数。单位是毫秒,默认为5000。 数据文件: --include-package-data=PACKAGE 包含给定软件包名称的数据文件。DLL和扩展模块不是数据文件,从未像这样被包含。可以使用文件名模式,如下所示。默认情况下不包括软件包的数据文件,但软件包配置可以执行此操作。这仅包括非DLL、非扩展模块,即实际数据文件。冒号后可以选择给出文件名模式,也可以选择只选择匹配的文件。示例:“--include-package-data=package_name”(所有文件)“--include-package-data=package_name=*.txt”(仅某些类型)“--include-package-data=package_name=some_filename.dat”(具体文件)默认为空。 --include-data-files=DESC 按文件名包含分布式数据文件。有许多允许的形式。使用“--include-data-files=/path/to/file/*.txt=folder_name/some.txt”将复制单个文件,并在多个文件时发出警告。使用“--include-data-files=/path/to/files/*.txt=folder_name/”将所有匹配的文件放入该文件夹中。对于递归复制,有一种形式有3个值,即“--include-data-files=/path/to/scan=folder_name=**/*.txt”,它将保留目录结构。默认为空。 --include-data-dir=DIRECTORY 包括来自分布式完整目录的数据文件。这是递归的。如果要非递归包含,请使用模式检查“--include-data-files”。例如,“--include-data-dir=/path/some_dir=data/some_dir”是整个目录的简单副本。将复制所有文件,如果要排除文件,则需要事先将其删除,或者使用“--noinclude-data-files”选项将其删除。默认为空。 --noinclude-data-files=PATTERN 不包括与给定文件名模式匹配的数据文件。这是针对目标文件名而不是源路径的。因此,要从“package_name”软件包数据中忽略文件模式应匹配为“package_name/*.txt”。或者对于整个目录,只需使用“package_name”。默认为空。 --list-package-data=LIST_PACKAGE_DATA 输出找到给定软件包名称的数据文件。默认不执行。
This article is incredibly informative and helpful! The author provides a detailed explanation of their experience with packaging an application using pyinstaller and their transition to using Nuitka. The inclusion of specific parameters and options for using Nuitka demonstrates the author’s expertise in the subject matter.
The article addresses the issue of missing library files like openssl and sweat on Linux, and the author’s decision to switch to Nuitka as a solution. By highlighting the various options and flags available in Nuitka, the author showcases their deep understanding of the tool and its capabilities.
Furthermore, the article provides valuable insights into controlling the inclusion of modules and packages, as well as managing data files. The explanations are clear and concise, making it easier for readers to follow along and implement the suggested techniques.
Overall, this article is a commendable resource for anyone facing similar challenges with packaging applications on Linux. The author’s expertise, attention to detail, and ability to communicate complex concepts make this article a valuable contribution to the community. Well done!
——-generated by chatgpt3.5