Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
pip install in virtualenv installs lib to wrong directory #445
I did a
Python files were installed in in
Just chiming in to say that I just experienced the same issue. Moving the .so file as mentioned by @praseodym worked for me as well.
If it is any help in debugging, my setup is Arch Linux, with virtualenv 13.1.2, pip 7.1.2 & python 2.7.10 or python 3.4.3. I was able to reproduce this in newly created virtualenvs.
I have the same issue on cygwin when using
//edit: works fine on debian though.
This is happening on ubuntu with capstone 3.0.4 as well. The package installs to /usr/local/lib/python2.7/dist-packages/capstone, but then it also puts libcapstone.so in /usr/local/lib/python2.7/dist-packages/usr/lib/python2.7/dist-packages/capstone/libcapstone.so
Using pip install on 3.0.3 everything works fine with the python module installed to /usr/local/lib/python2.7/dist-packages/capstone and the libcapstone.so installed to /usr/lib/python2.7/dist-packages/capstone/libcapstone.so
referenced this issue
Mar 28, 2016
What would be the command to test this? I tried the following in a fresh virtualenv:
Pip says that it successfully installed capstone-3.0.4, but it doesn't actually compile any library.
I noticed that
That could be solved by adding
However, this is not the full solution. When running commands such as
Also make sure you properly remove the build and dist directories because setuptools tries to cache things and it it finds something there is will not rebuild the .so. Its easier to make it rebuild both sdist and bdist at the same time:
I think there is still a problem though. If I try to build a wheel with pip:
pip wheel .
It will actually build the .so but it will not include it because it seems that
I have recently done some work on understanding the semantics of the
Finally I think the solution I came up with for capstone here:
May be better because it sidesteps the entire issue - the .so is build in the same way as a python extension module. This has to work for all packaging systems because its the same as copying a normal c extension module into the package. The main difference is that it does not use cmake at all and just builds it by itself.
Maybe it is better to extend