Hiya, do you plan to submit this into a openSUSE devel project? Or have you already attempted it.

I am currently doing a .spec which would be suitable for https://build.opensuse.org/project/show/devel:languages:python , using all of their macros so it is eligible , but unfortunately the python macros mean the .spec doesnt work on other distros, as I am sure you are aware. I am giving you credit in the .changes file as you've been maintaining it for so long here, and I am copied chunks of your .spec, which makes my involvement quite minimal.

You have such an impressive .spec here, supporting so many distros.

I wonder if this package is more suitable for submission to https://build.opensuse.org/project/show/devel:tools:compiler , where the maintainers are more likely to accept a cross-distro .spec file.

Kay Hayen (kayhayen) - about 5 years ago

maintainer

I never submitted it.

I want to use OBS to produce RPM packages for all the things. I am not sure what benefit the macros can provide, the packaging is not big I think, but also not good. The Python3 content and Python2 content are mixed, however I assume that problem is going away more or less automatically, isn't it, some Fedora soon will have no Python2 anymore.

---

John Vandenberg (jayvdb) - about 5 years ago

Unfortunately devel:languages:python is really strict about using their macros, so I am doing it their way.

Why did you use --skip-reflection-test ? Are those tests broken? on openSUSE? or some other reason?

I saw Nuitka was already going down this path, but it would be very useful if Nuitka converted cffi and ctypes to proper DSO dyn links. Then rpm packaging of python packages might use Nuitka to compile and then automatically read the runtime dso dependencies from the compiled version of the library, even if the compiled version is discarded and not shipped in the python packages.

Then we wouldnt need to explicitly list the Requires: libusb-1_0-0 in https://build.opensuse.org/package/view_file/devel:languages:python/python-libusb1/python-libusb1.spec?expand=1 - RPM voodoo could deduce it automatically, which isnt so brittle. That is an easy case, but there are much messier ones like https://build.opensuse.org/request/show/694846 where maintainers have previously chosen to use -devel in the runtime dependencies rather than list the real dependencies.

---

Kay Hayen (kayhayen) - about 5 years ago

maintainer

The reflection test is very CPU intensive and not going to find much issues. I am running it only from my buildbots here.

I absolutely will love to hit those goals related to ctypes. My initial plan was to be doing a dlopen() only, when CDLL is called, but by DSO dyn links, you would mean more. I am not sure they offer much benefit. Surely the runtime dependencies discovered by Nuitka can be output not only through a binary linkage.

But I will take note of the idea.

---

John Vandenberg (jayvdb) - about 5 years ago

Yes, a fallback would be for Nuitka to expose the list of library deps via another mechanism, possibly also doing a parse phase only to determine those, instead of a full compile needed to add DSO dyn links.

Another fun use of OBS would be to create a project with a large subset of https://build.opensuse.org/project/show/devel:languages:python in it, with lots of modules which depend on each other, and ensure using packages which have a working %check section in the .spec.

Then add a customised copy of https://build.opensuse.org/package/show/devel:languages:python:Factory/python-rpm-macros to the project so that the standard macros %python_build/%python_install use Nuitka to compile the packages, and install the compiled versions. Then the compiled version of the dependencies will be used by the other packages and their tests will also run. In theory, all packages should compile and all tests pass in all packages ;-) Or my guess is that will flush out a lot of interesting bugs. Would be a great GSOC project. ;-) There will be some minor problems with the spec files, esp in %files, especially any packages which install into the root of site-packages as their %files will have a __pycache__ entry which wont be needed for Nuikta compiled packages. Easy changes to the .spec's.