On Mon, Aug 1, 2016 at 1:42 AM Nick Coghlan <ncoghlan@gmail.com> wrote:
On 1 August 2016 at 05:27, Daniel Holth <dholth@gmail.com> wrote:
> The next version of cffi will contain small changes to generate code
> compliant with Python's Py_LIMITED_API:
> https://bitbucket.org/cffi/cffi/commits/8f867f5a869f
>
> (although cffi itself is not, the extensions it generates will be).

Very cool!

> If we also add an appropriate supported tag to pip ~= cp3.abi3.manylinux1
> and provide a way to name the generated DLL's appropriately, it may become
> possible to reduce the burden of distributing cffi extensions, especially
> for Windows. One compiled artifact should work on Python 3.2 and above.

Aye, that would be very promising. I guess the first step would be to
document the current steps involved in doing this manually? And then
figure out what tweaks would be needed to setuptools and pip to allow
it to be automated?

As an initial stab at that:

Status quo, on publication side:

- require minimum cffi version 1.8
- build with setuptools
- postprocessing step to rename shared library/DLL
- postprocessing step to regenerate renamed whl file with renamed SO/DLL

There wouldn't necessarily need to be renaming. build_ext command determines the DLL extension. It could be patched or modified to read an "I'm ABI3" flag on the Extension() object.

We could pass an ABI3 flag to bdist_wheel in the same way we ask for universal 'py2.py3-none-any'. To be set if the wheel contained only ABI3 extensions, and ignored on py2.


On consumption side:

- requires "cp3.abi3" to be included at appropriate points in
compatibility tag list

Which would make the necessary changes be:

- updating setuptools to somehow be Py_LIMITED_API aware when naming
built extensions
- updating wheel to somehow be Py_LIMITED_API aware when naming whl files
- if necessary, updating pip's compatibility tag list

Of those changes, only the "somehow be Py_LIMITED_API aware" sounds
potentially tricky to me, as I'd be surprised if there was any way
around requiring a new explicit setting in either setup.py or
setup.cfg.

Any alternative to an explicit flag that I can think of would be too magical to consider, as poor as trying to inspect library symbols for manylinux1 compat in bdist_wheel itself.
 
Regards,
Nick.

--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia