[PATCHES] Generate shorter name for extra python files
pviktori at redhat.com
Tue Aug 29 08:35:13 UTC 2017
On 08/27/2017 09:02 AM, Andrew Bartlett wrote:
> On Tue, 2017-08-22 at 11:25 +0200, Petr Viktorin via samba-technical
>> I'm sorry for missing this thread; my vacation-mode filtering is too eager.
>> As for the original design, "extra python" allows building two versions
>> of Python by a single `make` invocation. Building for both 2 and 3 at
>> once was a requirement to get the Python3 patches in.
>> To make this work, I've reused the mechanism Python uses to allow binary
>> files for multiple versions to co-exist. The "ABI tag" contains just the
>> information needed to distinguish between ABI-incompatible versions.
>> Note that "/usr/lib64/pkgconfig/pyldb-util36.pc" does not include all
>> relevant information: the "m" in "cpython-36m-x86_64-linux-gnu" encodes
>> build-time configuration; "dm" would mean a debug build with
>> incompatible ABI.
>> See [PEP 3149] if you want details.
>> Using the ABI tag as-is essentially puts the burden of distinguishing
>> ABI incompatibilities on Python developers/distributors. It's also quite
>> easy to ask Python for it , so, hopefully, buildsystems of packages
>> that depend on the utils can be made to support this.
>> That said, I'm not familiar with pkg-config or multilib packaging
>> outside of Python, or across distros. This is the Python way to do it;
>> please adjust if it makes sense.
>> Another note on the original design intent: generally, the "extra
>> python" needs to be version 3, and the "normal" Python could be either 2
>> *or* a different version of 3. It's never been tested with py3 as the
>> non-extra Python, and I'm sure it doesn't actually work now, but at some
>> point it'll be necessary to make the "non-extra" Python be Python 3,
>> preferably with the relevant name mangling. Please don't assume that
>> "not extra-python" implies Python 2.
>> [PEP 3149]: https://www.python.org/dev/peps/pep-3149/
>>  import sysconfig; sysconfig.get_config_var('SOABI')
> Thanks for the details. If you could work with Lumir and Andreas to
> propose something that follows the above and meets Lumir's requirements
> that would be great. We can't be the first package to have produced a
> python C binding, surely there is some guidance already?
Samba is not the first package with a Python binding, but those "_util"
libraries are quite unique.
General guidance for providing a C API for Python extension modules is
provided in Python documentation : roughly, put the function pointers
(and a version) in a struct, wrap it in a Capsule object, and provide
that as a Python-level object.
To use this, there's a PyCapsule_Import helper that imports a module,
fetches the attribute, and unwraps it to get the struct.
This solves problems with naming/discovery/linking of C-level utilities:
everything is found via the extension module.
But in Samba's case, it would require changes to all code that currently
uses the _util libraries.
More information about the samba-technical