You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ImportError: DLL load failed: The specified module could not be found. #158
I never used pipenv, so take this with a grain of salt: shouldn't you enter into / activate the virtualenv in some way, before trying to load the package?
So, that output does not help. Can you check the output of python -c "import sys; print(sys.path)", and see if you can spot a difference between where it works and where it does not?
No: binary wheels are built by an automatic process, and you can see that PyPI carries both the 32 bit and the 64 bit wheels.
So I still think that the problem is related to why one of your pipenv environments selected the wrong package.
As said, I do not use pipenv and neither Windows, so I can be of very little help there, sorry!
But I assume that pipenv emits log when it install the packages...
Can you inspect python3 -c "import sys;print(sys.implementation)", that should contain some information about the underlying architecture (for example, mine shows _multiarch='x86_64-linux-gnu', and then I find rapidjson.cpython-39-x86_64-linux-gnu.so under env/lib/python3.9/site-packages).
Yes, it could be. As said, unfortunately I'm not able to provide useful help, as I do not have Windows machines around.
Are you able to collect some info about that dependency, like version or the like?
Activity
lelit commentedon Jul 14, 2021
That's strange: on one hand little has changed since version 1.0, and on the other, Windows specific tests pass...
Are you sure you are trying to load the package with the right Python interpreter, the one used to install it?
Does
python -v -c "import rapidjson"emit something that may help diagnosing the problem?lelit commentedon Jul 14, 2021
I never used
pipenv, so take this with a grain of salt: shouldn't you enter into / activate the virtualenv in some way, before trying to load the package?lelit commentedon Jul 15, 2021
So, that output does not help. Can you check the output of
python -c "import sys; print(sys.path)", and see if you can spot a difference between where it works and where it does not?lelit commentedon Jul 15, 2021
Also, have you tried creating a new virtualenv from scratch and see if it does make any difference?
lelit commentedon Jul 16, 2021
Great, so the problem is with the pipenv tool, that selected the wrong architecture?
lelit commentedon Jul 16, 2021
No: binary wheels are built by an automatic process, and you can see that PyPI carries both the 32 bit and the 64 bit wheels.
So I still think that the problem is related to why one of your pipenv environments selected the wrong package.
lelit commentedon Jul 16, 2021
As said, I do not use pipenv and neither Windows, so I can be of very little help there, sorry!
But I assume that pipenv emits log when it install the packages...
Can you inspect
python3 -c "import sys;print(sys.implementation)", that should contain some information about the underlying architecture (for example, mine shows_multiarch='x86_64-linux-gnu', and then I findrapidjson.cpython-39-x86_64-linux-gnu.sounderenv/lib/python3.9/site-packages).lelit commentedon Jul 16, 2021
Sure, enjoy your pause!
lelit commentedon Aug 12, 2021
Yes, it could be. As said, unfortunately I'm not able to provide useful help, as I do not have Windows machines around.
Are you able to collect some info about that dependency, like version or the like?
vellrya commentedon Nov 26, 2021
Solution is very easy: we should install Visual C++ Redistributable package first.
It can be downloaded from here: https://docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist
lelit commentedon Nov 27, 2021
Thank you! Maybe we could add a note somewhere...