> use AddDllDirectory, (which is as accessable as os.environ['PATH'] but is not considered a security risk so far)

The parenthical is incorrect. The user-specified DLL search directory is separate from PATH, and both appear in the default DLL search order when resolving relative paths. In more secure configurations, PATH is not used for DLL resolution.

> but this requires using SetDefaultDllDirectories which breaks other things

Specifically, it breaks any extension relying on the implicit default search order by enabling one of the more secure configurations.

> put any dlls required for the c-extension pyd in the same directory which means scipy and numpy will be using duplicate and potentially different OpenBLAS dlls, and whoever imports first wins

Doesn't scipy import numpy? Which means numpy wins every time. Or alternatively, put "-numpy" in the name of numpy's one and "-scipy" in the name of scipy's one, and you can have both.

> load all the required dlls via LoadLibrary, meaning NumPy will have to export a windows-only API to SciPy so the latter can know where the DLL is.

Perhaps that API could be exported via normal module import as is currently is? That way scipy can just "import numpy" to locate numpy?

Alternatively, if you do indeed need to have shared state with scipy, then you should come up with an API that they can depend on. This is how shared state normally works.

> Is there a PEP that describes the overall design of windows directory layout or a design guide for package authors with best practices for additional dll dependencies?

No, but there is a doc page that deserves an update: https://docs.python.org/3/extending/windows.html

If we make a dramatic change to CPython here, then there may be a PEP, but it should still defer to the documentation as that is what gets updated over time.

Currently, the best info comes from https://docs.microsoft.com/windows/desktop/Dlls/dynamic-link-library-search-order and awareness that only the LOAD_WITH_ALTERED_SEARCH_PATH flag is used when loading extension modules (see https://github.com/python/cpython/blob/master/Python/dynload_win.c#L221)


Since I just saw the confirmation at https://docs.microsoft.com/en-us/windows/desktop/Dlls/dynamic-link-library-search-order#search-order-using-load_library_search-flags, I don't think we can safely change the LoadLibraryEx option in CPython until we drop support for Windows 7 completely, as the update containing the new flags may not be installed. If/when we do that, it will break any extension relying on unsafe DLL search semantics (that is, anything appearing in the earlier section but not in this section).