BUG: windows dll install directory changed from scipy/.libs to scipy.libs

Describe your issue.

From scipy 1.9.1 to scipy 1.9.3 the directory used to install dlls on windows changed. scipy-1.9.1: dlls are installed in …/site-packages/scipy/.libs scipy-1.9.3: dlls are installed in …/site-packages/scipy.libs

This causes pyinstaller builds using scipy-1.9.3 to fail as the expected dll location changed.

If this change was intented I will file a bug report with pyinstaller to update the scipy installer hook.

Reproducing Code Example

None

Error message

None

SciPy/NumPy/Python version information

1.9.3 1.23.1 sys.version_info(major=3, minor=10, micro=6, releaselevel=‘final’, serial=0)

[andyfaff]

It’s not cibuildwheel that controls where the bundled dlls end up, it’s down to the tool that repairs the wheel. For Windows this is delvewheel, for macOS it’s delocate and on Linux it’s auditwheel. One can use the -L, --lib-sdir option to control where the vendored dlls are stored, but package-name/.libs is the default. I believe this is the same behaviour as delocate except that tool uses package-name/.dylibs

[rgommers]

It’s whatever the default of the tools doing the shared library vendoring is. I don’t think we care too much either way. If I had to choose, I’d probably stay with .libs, but it’s not a big deal.

I thought it was wise to retain the standard behaviour of the repair tool.

Same here