On 22Jun.2019 1404, Phil Thompson wrote: > The implementation of issue 36085 breaks PyQt on Windows as it relies on > PATH to find the Qt DLLs. The problem is that PyQt is built using the > stable ABI and a single wheel is supposed to support all versions of > Python starting with v3.5. On the assumption (perhaps naive) that using > the stable ABI would avoid future compatibility issues, the existing > PyPI wheels have long been tagged with cp38. > > Was this issue considered at the time? What is the official view?
The official view is that using PATH to locate DLL dependencies is a security risk and has been deprecated by Windows. The new Store package already ignores PATH when resolving DLLs, and the change to 3.8 brings all deployments of Python on Windows into line, as well as adding the os.add_dll_directory() function that your package can use to add *only* the directory it needs. I'm sorry we didn't promote the change widely enough for you to hear about it prior to 3.8.0b1 being released, but it was made deliberately. As far as I'm aware, there are no interactions with the stable ABI here. The compatibility issue is that Windows is (slowly) dropping support for the search path you were relying on, and ultimately there is no way around that. Rather than having to tell some subset of end-users that your package won't work for them, we decided to aim for consistency and provide package developers with the means to fix it themselves. Developers from numpy, scipy and Anaconda were involved in the discussion. The section of the porting notes dealing with this issue is https://docs.python.org/3.8/whatsnew/3.8.html#bpo-36085-whatsnew Cheers, Steve _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/R5RIBKDOH3J5ZBI22J3VHQWD4PEUTGWK/
