On 12 January 2017 at 21:26, Alec Leamas leamas.alec@gmail.com wrote:
On 12/01/17 12:02, Alec Leamas wrote:
It's "my" code, I'm upstream for an old package for which I'm about to add a python API. Haven't found any pointer how to make pypi package with linux native code... have you?
At a second thought, I don't think I wan't this. My users will need the real package (lirc) anyway; this is compiled code which typically is installed using package managers. Adding the python API to the core package means that neither building nor headers are required after installing the package, and I'm pretty sure pypi doesn't solve that in a better way.
The main cases where I've personally found "system package only" to be a genuine pain is when doing cross-version compatibility testing with tox for projects that still support Python 2.6.
As a specific example, you can't readily run the Anitya tests under Python 2.6 on Fedora, as even though there's a python26 package, there's no corresponding RPM bindings for it, and hence "import rpm" fails even with --system-site-packages enabled.
The same problem comes up in reverse on RHEL/CentOS where the newer runtimes available via EPEL or Software Collections are missing most system packages and hence rely almost entirely on PyPI.
That said, there's an eminently practical way to avoid those problems in many cases: run a recent Fedora container image atop a RHEL or CentOS container host rather than running directly on the host.
Cheers, Nick.