Package request: python3-nuitka

[michalszmidt]

Package name

python3-nuitka

Package homepage

https://github.com/Nuitka/Nuitka

Description

Nuitka does Ahead Of Time (AOT) compilation of your python project to C. Thus it allows to create real executable.

It slowly being adopted in some apps. Like here, see source/Makefile in
https://gitlab.com/zehkira/monophony

So If I would like to package monophony for void I am unable to do so.

Possible other benefits would be to repackage some popular python "executables" that we already have in void. (And make them default?)

We could also add build style python3-nuitka to void build system.

Current blockers:

• python3.12 support in nuitka (or lack of distinguished python 3.11 build style)

Does the requested package meet the package requirements?

Required

Is the requested package released?

Yes

[classabbyamp]

python3.12 support in nuitka (or lack of distinguished python 3.11 build style)

the python3.11 package is not designed to support building python modules for general use, it is mostly for packages (like chromium) that need python in their build process but can't use 3.12 yet

if python3.11 was used to build the package, it would not work on install for users because the system python version is still 3.12

[chrysos349]

So If I would like to package monophony for void I am unable to do so.

#45416

[michalszmidt]

#45416

Good to know somebody already tried it!

All in all we have to wait for python 3.12 support Nuitka/Nuitka#2433

However I believe nuitka should be merged in dedicated commit and has great potential and benefits. And it's adoption may be discussed more broadly (here?)

[classabbyamp]

based on how long it appears to take them to be compatible with new python versions, this is probably not a good fit for void. void tries to bump its python very soon after the upstream release, so this would either hold everything up or be broken for months each year. neither seems like a good experience for users.

also, the way python works on void (and linux generally) does not need apps to be packed into a binary: there are system python modules that applications can rely on and (on void, at least) applications and libraries have python bytecode compilation at install-time.

[ahesford]

I definitely would not let such a special-interest package like this hold up the annual Python update, and agree that routinely breaking the package with updates would be a terrible experience that militates against packaging for Void.

As abby notes, the python3.11 package exists only to support a few packages that require Python to build (and vendor the packages they require for the process) and cannot build with the newer system version. Users are free to install that package and build virtual environments with it, but system packages that attempt to build modules for python3.11 or link its libraries will not be allowed.

[michalszmidt]

based on how long it appears to take them to be compatible with new python versions, this is probably not a good fit for void

I definitely would not let such a special-interest package like this hold up the annual Python update

Yeah, you are absolutely right. That would break great voidlinux experience.

Do you prefer to close that issue or to leave it open for other contributors that would maybe rise this subject in a future?

[ahesford]

We can always refer to a closed issue should somebody open another.