Nuitka 路线图
内容
Nuitka 路线图¶
这是Nuitka的路线图,按功能细分。
用户可扩展性¶
从 0.6.18 开始,数据文件、隐式导入都是 yaml 格式,但即使是 DLL 的包含,以及插件的位置也应该以 yaml 格式指定。
这样一来,由第三方扩展就变得更容易了。我们甚至可以想象,通过这样的文件,支持那些提供自己的配置与 Nuitka 进行编译的软件包。
这是从
anti-bloat
、data-files
和implicit-imports
插件的 yaml 配置开始的,并将从那里扩展。
单机版¶
“多分布” 支持(未定)
Allow combining multiple main programs into one, called “multidist”. These will work with a dispatcher that decides from the binary name what it is. There will be one big binary with the ability to run each program.
加速模式的 CMD 文件,展示了从另一个目录加载 CPython DLL 的可能性。我们可以利用这种方法,产生 CMD 文件,以正确的方式调用二进制文件。
我相信我们可以使所有的脚本在执行过程中仍然认为自己是
__main__
的__name__
,所以不需要修改代码。只是sys.argv[0]
与__file__
的位置问题。Much like for onefile, you need to distinguish program location and package location in this way. Note shared stuff living near the CMD file will see that CMD file path in
sys.argv[0]
there, and shared stuff, e.g.xmlschema
module will find its data files in a directory that is shared.最重要的是,”multidist” 的胖二进制可以是独立的或单文件模式,由你选择。其缺点是,单文件的解压速度会比较大的二进制文件要慢。
“Sharedist” 支持 (未定)
在这一点上,程序没有被合并,而是恢复了独立的编译,产生了多个分布的共享和非共享部分。
Nuitka 中的插件在复制 DLLs 和数据文件时仍然有些野蛮,有时,但不总是,向核心报告,所以它可以扫描依赖性。我们正在努力清理它们。有些,最近的 numpy,已经被改变,使它们产生描述任务的对象,并在核心中执行它们。这样就有机会知道程序是做什么的,并做出这种改变。这种过渡几乎已经完成,但 Qt 插件仍未完成。
My goal here is to say that e.g. a data file should be what Nuitka commercial currently calls “trusted” independent of it being a data file, right now that is not the case, but Nuitka is much closer to that now. This is of course the same with multiple distributions.
对于数据文件,这个插件可以用大致相同的方式钩住数据文件的复制过程,并将数据文件放在可执行文件附近或共享区域。
Windows:提供 CPython 的构建,允许静态链接,避免 CPython DLL。
强制输出和 stderr 到文件应该支持所有操作系统。
Dejong Stacks: 更强大的解析器,允许在同一文件中的 stdout 和 stderr 混合输出。
Add ability to inhibit data files from the command line, so that things coming from a plugin can be suppressed.
增加对 upx 的支持(公共功能)。
UPX不能压缩有效载荷,这就是为什么我们不能使用它并期望它能解决单文件压缩问题。然而,对二进制文件的后期处理,甚至是来自 CPython 扩展模块的二进制文件的后期处理,似乎已经能够发挥作用,并减少二进制文件的未压缩尺寸。
Nuitka-Python (public)¶
这一点目前正在进行中,这里还没有描述。目前的 Nuitka 版本已经支持使用它。大多数工作现在都集中在 Linux 和 Python2.7 上,目的是让它能够静态编译 numpy 以提高速度。
Performance (public)¶
Caching of demoted to bytecode modules. Some of these, e.g.
pkg_resources
take very long to analyse in Nuitka, just to find out the imports. There is no point in repeating this, a caching of Python compilation is a separate line of action, but it should start with this.Faster attribute setting.
For Python3 we still use
_PyObjectDict_SetItem
which is very hard to replace, as it’s forking shared dictionary as necessary. With static libpython it can linked though, but we still might want to make our own replacement.Better code for
+= 1
constructs with no lack of type knowledge. There is a long standing todo, to add theCLONG
support for binary operations. It requires the code generation of Jinja to be abstract, but that should have been close to being reached in last releases.Better code for
+= 1
constructs even with lack of type knowledge.It should be possible to introduce prepared constants of
nuitka_int
type that have the object ready for use, as well as the integer value, and indicate so with the enum setting. This type, that is intended for use with local variables later on, could also be supported in binary operations and in-place operations, esp. forint
,float
andlong
values.Make module variable traces available to functions. This will be needed to optimize import of
sys
on module level and then attribute access on function level at compile time.Implement the
partial
built-in and make it work with compiled functions. It could prepare calls much better, such that they do not come through keyword arguments unnecessarily.Take advantage of
list.append
representing nodes that these are in fact compile time constants and generate more efficient code for them, which some of the C implementations could use, examples would bestr.upper
where we only call that cached attribute value.Complete
str
built-in methods for enhanced results, esp. for compile time optimization.Add support for
list
methods, things likeappend
really should be optimized as well in the mostly existing operation nodes.
macOS enhancements¶
The macOS bundle mode and onefile are not yet working together, which needs mainly just internal changes for where to put files. Also for accelerated programs, bundle mode is not usable, so they couldn’t be GUI programs yet.
Apple Python must be detected and rejected for standalone mode.
Container Builds (commercial)¶
Providing docker images like manylinux
does with Nuitka installed into
all of them and ready to use. Might make this a free feature once it’s
done and supports --commercial
download of the plugins nicely.
Providing containers with old Linux, and optimally compiled CPython with podman such that building with Nuitka on Fedora latest and Ubuntu latest can be done fully automatically and still run on very old Linux. Right now this is implemented, but works mostly locally and needs more work than it should.
Support for Next Python Version (3.10)¶
Get it to work for 3.9 test suite.
The suite still needs a bit of help to run through, should be good though.
Add support for all of the new case syntax of 3.10
This is partially done, but assignments in or matches do not work yet.
Wheels Build¶
Needs more documentation and addition of (some) command line options of Nuitka to the
bdist_nuitka
target.
Traceback Encryption (commercial)¶
Right now tracebacks are entirely encrypted. But in a future update, you can decide which information is transferred, and what information is part of the encryption, and which part is not, e.g. hostname, client name, etc. could be output in plain text, while the variable names and values would not be, depending on your choice!
Features to be added for 0.6.20¶
[ ] Better scalability
[ ] Caching for bytecode demoted modules so no optimization needs to be run.
[ ] Compression of onefile with bootstrap before Python3.5, so far it’s there for 3.5 or higher only.
[x] Make pydantic
support the default, removing the experimental flag
function-base
with it being the default behavior.
Features to be added for 0.6.21¶
- [ ] Add ability to inhibit data files from the command line, so that
things coming from a plugin can be suppressed.