Re: rust and python

On 06/01/2026 15:45, Christoph Reiter via Cygwin-apps wrote:
> On Tue, Jan 6, 2026 at 4:19 PM Marco Atzeri <marco.atzeri-Re5JQEeQqe8AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> wrote:
>>
>> On 06/01/2026 15:21, Christoph Reiter wrote:
>>> On Tue, Jan 6, 2026 at 2:03 PM Marco Atzeri <[email protected]> wrote:
>>>> Anything else I should add to a respin of 3.12.12 and 3.9.16 ?
>>>
>>> You could add stable ABI/limited API/abi3 support
>>> https://github.com/msys2/MSYS2-packages/blob/b2b1757ab8752919afea4d0a7c1367dd77729292/python/991-py-limited-api.patch
>>> (and replace msys-python3.dll with libpython3.dll in there)
>>>
>>> Note that that contains a symbol list generated for 3.12 and I don't
>>> know if that works for older Python versions. And with the DLL not
>>> being versioned, only one package can provide it.
>>> To regenerate the list you'd need to `python
>>> ./Tools/build/stable_abi.py --generate --cyg-python3dll
>>> PC/cyg-python3dll.c Misc/stable_abi.toml` with that patch applied.
>>
>> This does not seem a good idea. I do not have the bandwith to update all
>> packages at the same time so multiple version will be always
>> present.
> 
> Yeah, hm, I'm not sure how to handle that best in a distro with
> multiple parallel versions. On Linux it's easy because there are no
> file name conflicts and no explicit linking in extensions.

I don't quite understand the use case for extensions linked against the 
"limited API"

In our packaging pipeline, because the binary wheel only exists 
transiently before we turn it into an installed package for a specific 
python version, there doesn't seem any advantage to that.

(and indeed, as you point out, because the shared library name is fully 
resolved for PE, it's actually still linked against the runtime for a 
specific python version...)