-
Notifications
You must be signed in to change notification settings - Fork 65
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
Unable to find DLLs on Windows using PythonCall with Python3.8+ #457
Comments
In the default
This shows that the correct paths have been added in the default Julia enironment. |
I modified the
|
Quoting from the OP:
The
And this fixes the issue. See below:
Maybe there is a better way or location to make the |
What you are experiencing is actually a bug in Python 3.10.0 which has been fixed in 3.10.2. From this line of
I can see that you have the buggy Python 3.10.0 installed. This happened because you added Python like You probably actually wanted Note that this prevents any newer Python from being used. Unless you really do need Python 3.10 it's generally recommended to do something like |
Closing as I believe this issue is solved. |
Affects: PythonCall / JuliaCall(Maybe)
Describe the bug
Using a project folder environment for a Julia project with
julia --project=.
and when trying to use PythonCall along with CondaPkg with numpy on Windows 10, with Julia 1.10 I get the following error:This however does not happen when running in the default Julia environment
(@v1.10)
Expectation:
using PythonCall
should work without issues (as on Linux)Steps to Reproduce
julia --project=.
inside a temporary folder OR start Julia and] activate .
Your system
OS: Windows10
Julia Version: 1.10
Python Version: 3.10
PythonCall Version: v0.9.15
Output of Pkg.status():
Output of CondaPkg.status():
Additional context
The issues #146, #245, #339, #373 seem to also be affected by this.
On a bit of further reading on stack overflow, I found out that this issue is related to loading the DLLs on Windows. The Python 3.8 release notes state:
DLL dependencies for extension modules and DLLs loaded with ctypes on Windows are now resolved more securely. Only the system paths, the directory containing the DLL or PYD file, and directories added with add_dll_directory() are searched for load-time dependencies. Specifically, PATH and the current working directory are no longer used, and modifications to these will no longer have any effect on normal DLL resolution. If your application relies on these mechanisms, you should check for add_dll_directory() and if it exists, use it to add your DLLs directory while loading your library. Note that Windows 7 users will need to ensure that Windows Update KB2533623 has been installed (this is also verified by the installer). (Contributed by Steve Dower in bpo-36085.)
The text was updated successfully, but these errors were encountered: