<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Aug 1, 2016 at 1:42 AM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1 August 2016 at 05:27, Daniel Holth <<a href="mailto:dholth@gmail.com" target="_blank">dholth@gmail.com</a>> wrote:<br>
> The next version of cffi will contain small changes to generate code<br>
> compliant with Python's Py_LIMITED_API:<br>
> <a href="https://bitbucket.org/cffi/cffi/commits/8f867f5a869f" rel="noreferrer" target="_blank">https://bitbucket.org/cffi/cffi/commits/8f867f5a869f</a><br>
><br>
> (although cffi itself is not, the extensions it generates will be).<br>
<br>
Very cool!<br>
<br>
> If we also add an appropriate supported tag to pip ~= cp3.abi3.manylinux1<br>
> and provide a way to name the generated DLL's appropriately, it may become<br>
> possible to reduce the burden of distributing cffi extensions, especially<br>
> for Windows. One compiled artifact should work on Python 3.2 and above.<br>
<br>
Aye, that would be very promising. I guess the first step would be to<br>
document the current steps involved in doing this manually? And then<br>
figure out what tweaks would be needed to setuptools and pip to allow<br>
it to be automated?<br>
<br>
As an initial stab at that:<br>
<br>
Status quo, on publication side:<br>
<br>
- require minimum cffi version 1.8<br>
- build with setuptools<br>
- postprocessing step to rename shared library/DLL<br>
- postprocessing step to regenerate renamed whl file with renamed SO/DLL<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On consumption side:<br>
<br>
- requires "cp3.abi3" to be included at appropriate points in<br>
compatibility tag list<br>
<br>
Which would make the necessary changes be:<br>
<br>
- updating setuptools to somehow be Py_LIMITED_API aware when naming<br>
built extensions<br>
- updating wheel to somehow be Py_LIMITED_API aware when naming whl files<br>
- if necessary, updating pip's compatibility tag list<br>
<br>
Of those changes, only the "somehow be Py_LIMITED_API aware" sounds<br>
potentially tricky to me, as I'd be surprised if there was any way<br>
around requiring a new explicit setting in either setup.py or<br>
setup.cfg.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regards,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</blockquote></div></div>