Re: To use or not to use: packaged flask
On 12 January 2017 at 21:26, Alec Leamas <leamas.alec(a)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.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia