I’m trying to install
pyreadr on a windows virtual machine using pip.
When doing so the
.dll files all save in:
rather than in
which is causing the import of the package to fail.
Is there are way of forcing the
.dll files to be include with the rest of the package in the second location?
Oddly, the package includes the DLLs as data files that get installed in the relative path “Lib/site-packages/pyreadr”. This works if the package is installed to Python’s system site packages or a virtual environment. But
--user package installations use “%AppData%\Python” as a common base directory for data files. I’d prefer to completely isolate
--user installations by Python version, including the data files directory, but that’s a separate issue.
The package should not include the required DLLs as data files. They should be installed either beside the
librdata extension module, or in a subdirectory in the package that gets added to the DLL search path via
Thank you very much for your response.
I suppose this means that there is no solution at present other than to manually move the files?
If you check the wheel (it’s a zip archive), you’ll see that the DLLs are in the package directory for data files. You’re stuck with this incorrect layout, unless pip has an option to override the base directory for package data files, which I don’t think it does. You could open an issue on the package’s GitHub repo to inform the developer(s) that
--user installs are wrong in Windows because of the misuse of
It should work correctly when installed into Python’s system site packages or a virtual environment. It’s only broken for
--user installs. As a workaround, you could move, copy, hardlink, or symlink the DLLs into the package directory. Or you could temporarily add the directory where they’re installed to the DLL search path via
os.add_dll_directory(). Here’s an example of the latter:
data_dir = sysconfig.get_path('data', 'nt_user')
pyreadr_dll_dir = os.path.join(data_dir, r'Lib\site-packages\pyreadr')