On Mon, Aug 1, 2016 at 1:42 AM Nick Coghlan <[email protected]> wrote:
> On 1 August 2016 at 05:27, Daniel Holth <[email protected]> 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 | [email protected] | Brisbane, Australia >
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
