Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows: Fixed FileNotFoundError when copying dependencies to the project folder #285

Closed
wants to merge 1 commit into from

Conversation

Ati1707
Copy link

@Ati1707 Ati1707 commented Aug 6, 2024

If you copy the dll files to the project folder. It will throw a FileNotFoundError because of the default CDLL mode(LOAD_LIBRARY_SEARCH_DEFAULT_DIRS).
It expects a full path to the file but for some reason ctypes.util.find_library only returns the file name if its in the project directory next to the mpv.py. Thats why the workaround(#60 (comment)) putting the dependencies in the script folder works since it returns the full path.
Adding winmode=0 fixes this issue and the user can now put the dependencies in the project directory or in the script folder.
For unit tests you would need to copy the dependencies in the tests folder as well.

It might be better to use a different approach to find the dll but this might be enough since it shouldn't break anything if it does let me know.

Closes #104

@Ati1707 Ati1707 changed the title Fixed FileNotFoundError when copying dependencies to the project folder Windows: Fixed FileNotFoundError when copying dependencies to the project folder Aug 6, 2024
@jaseg
Copy link
Owner

jaseg commented Aug 14, 2024

Adding winmode=0 re-enables searching the CWD, which I think got removed for a good reason.

The underlying issue seems to be that ctypes.find_library searches through %PATH% using string substitutions. When all entries in %PATH% are absolute paths, that will work since passing an absolute path to CDLL later will override the search order anyway. However, when find_library finds the DLL based on a relative path in %PATH%, that will cause the subsequent call to CDLL to choke when the resolve path that DLL is under is not one searched by LOAD_LIBRARY_SEARCH_DEFAULT_DIRS.

After relying on %PATH% so far, I don't really want to change that behavior. We could ad-hoc register any relative path returned by find_library using os.add_dll_directory, but that would affect the whole process, which I'm not a huge fan of. I think for now, the right fix is to just adjust the error message, and tell the user to only ever use absolute paths in %PATH%, combined with calling CDLL with LOAD_LIBRARY_SEARCH_DEFAULT_DIRS | LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR to make sure any possible dependency DLLs of libmpv also get loaded (not sure if there are any on Windows atm).

@jaseg
Copy link
Owner

jaseg commented Aug 14, 2024

I've just pushed a change to main that improves the error messages and adds the new flags to the CDLL call. Please see if that does what you want, and feel free to re-open the PR if it doesn't.

@jaseg jaseg closed this Aug 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cannot find mpv-1.dll
2 participants