adang1345 / delvewheel

Self-contained Python wheels for Windows

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Anaconda and `os.add_dll_directory`

njroussel opened this issue · comments

Hi!

I just came across your commit e4d5c91.

I'm running into similar issues with conda where it is not correctly handling the os.add_dll_directory instructions. I was planning to implement the same workaround you had, where we enable the CONDA_DLL_SEARCH_MODIFICATION_ENABLE flag (environment variable).
The fact that you're reverting this fix and the commit description both suggest that there are still a few issues with this solution. Would you mind sharing your findings with me?

For reference, this issue is where I first encountered this.

Hi, my findings have been that the CONDA_DLL_SEARCH_MODIFICATION_ENABLE workaround is suitable in some situations and not others. If CONDA_DLL_SEARCH_MODIFICATION_ENABLE is 1 at the time when an extension module is imported, then paths added with os.add_dll_directory() will be searched.

My first attempted solution to my problem was that I would do os.environ['CONDA_DLL_SEARCH_MODIFICATION_ENABLE']=1 prior to importing an extension module whenever Anaconda Python >=3.8 was used. This initially worked fine in my testing. However, I received a bug report that some third-party Python modules break when CONDA_DLL_SEARCH_MODIFICATION_ENABLE is 1. So if the user tries to import one of these third-party modules afterward in the same process, the import would fail. One way to solve this is to revert CONDA_DLL_SEARCH_MODIFICATION_ENABLE back to its original value as soon as the extension module was imported. For technical reasons that aren't worth describing further, this solution did not fit with my project, so I had to do something different. However, it might work with yours.

To get CONDA_DLL_SEARCH_MODIFICATION_ENABLE to work properly, you need to set it to 1 right before importing your extension module and then set it back to its original value right afterward. In addition, your extension module cannot try to import one of those problematic third-party module in its PyInit function, and no other thread can be trying to import a problematic third-party module at the same time.

Thanks @adang1345 !
That was what I expected, thank you for confirming it.