I tried to find solutions on simillar threads but really can't find any.
Can't install packages due to an error WinError 123 as shown on image below:
Image here!
I find it weird that in path there is 'sC' term at the end.
I tried to reinstall and install different versions of python but it happens on all as I assumme that is a Windows problem.
ENV definitions pt.1
ENV definitons pt.2
During investigation i put print command in path and mkdir function variable called 'name'. Everything goes well over there but i found a problem at last few lines:
Problem
So the last Path is corrupted as it adds a 's' character and repeats the path again, and when tool is cropping the path it leaves it with just sC signs.
Well... it took rather longer distance than i thought and of course the answer is simple.
Easiest way is to run:
pip config debug
and localize your installing paths:
Here is the output:
I saw there was a weird one over there at global.target variable which I did not modify. Easy solution, just change pip.ini file so the path is actually the path you want your libraries to be stored at.
Related
I'm running a code on deep learning, which uses the opencv module, by running python main.py (contains import cv2 statement), but always get the error 'ImportError: dynamic module does not define module export function (PyInit_cv2)'.
I've tried to reinstall my anaconda and create new virtual environments, but all got the same result. This problem really confuses me a lot and I've googled for many related problems, none of them works. I think the problem is something related to the environment and has nothing to do with the code, because I got the same result by simply run import cv2 in python prompt. The more confusing thing is that, even after I remove the opencv module, I also get the same problem, but not a ModuleNotFoundError. Does anyone can give me some advice? Thanks a lot!
I think I found one possible reason of this error.
Recently I was configuring the caffe environment on one server, I downloaded the source code of opencv-2.4.13 and compiled manually, added /usr/local/opencv-2.4.13/build/lib to $PYTHONPATH, and caffe worked well. After that, when I entered one of my virtual environment using conda activate py35, which uses python3.5, tried import cv2 in the python prompt, got the error above.
I'm not sure but I think the cause of the error is opencv-2.4.13 compiles a python2 interface so it can't be imported by python3. Python imports packages by searching the directories listed in sys.path, where $PYTHONPATH is in the second place after the current working directory (This is a great article introduces the mechanism of python finding packages). So when we enter the py35 environment, python will first look for $PYTHONPATH and find the opencv installed on the root directory instead of finding the opencv in the virtual environment using conda install opencv-python.
So there are two solutions of this problem:
Use python2 instead.
Remove /usr/local/opencv-2.4.13/build/lib from $PYTHONPATH.
which all work for me.
Similar post, might help:
ImportError: dynamic module does not define init function (initfizzbuzz)
Could you provide info on how you installed the CV module?
I had the same problem, which was caused by the cv2.so file in /usr/local/lib/python2.7/site-packages/cv2.so. After I deleted the file and use command sudo pip3 install opencv-python, it worked for python3.
C:\ProgramData\Miniconda3\pkgs\plotly-3.1.1-py36h28b3542_0\Lib\site-packages\plotly
C:\ProgramData\Miniconda3\Lib\site-packages\plotly
What is the difference between these?
my code tries to pull from the second location but doesnt find things.
for example, it will tell me my module 'plotly.figure_factory' has no attribute 'create_choropleth' or something
so I transferred the files from the first location to the second one and it found them.
Pkgs directory is somewhere to place the package downloaded and unzipped. So it is a full and complete scripts/project documents.
Actually, the second one should have the file you want if you installed the package properly. I think maybe there are some problems during installing or you just install it into some sub-environment of miniconda instead of the global environment of miniconda. So there will be some left packages which are downloaded and unzipped but not installed.
You could also copy and paste the file from the first location to the second one by yourself. If you could import properly, it should be ok.
so I tried to set up an working environment to code some stuff with python. I used this really nice website newcoder.io to do it the right way.
Unfortunately I came across a big problem I cannot solve by myself even after several hours of trial and error (sponsored by Google).
I installed all required packages starting from python, virtualenv, virtualenvwrapper. I also changed the .bashprofile for using Terminal as stated. Then I tried to test the working environment like described in the aforementioned website newcoder.io Test.
As I was within the working environment named "TestEnv" I tried to install django via pip. Here is the result coming from Terminal:
(TestEnv)username:~ username$ pip install django
-bash: /Users/username/.virtualenvs/TestEnv/bin/pip: "/Users/brokenusername: bad interpreter: No such file or directory
As you can see there seems to be something wrong with the underlying links. I have to admit, that I recently changed my account name and the name of the home directory in OS X Mavericks (see "username" and "brokenusername" within the code). Everything went fine so far. The username is now without blank spaces in the name (a different, bigger problem, but solved). But pip still seems to keep the old "brokenusername".
My Question is, how do I change the "brokenusername" to "username" so that pip is able to its work.
Thanks for all advices.
Here is a sloth for all your efforts to help !
Please note: I am newbie when it comes to understand and change these kind of working environments. I tried my best to find a solution by myself. But it seems like I need some advice from the Internetz.
virtualenv creates symlinks, environment variables and other path links in places like .pth files that are invalidated when you change the base path of the env. But environments are cheap to create so (assuming you haven't placed other files in the virtualenv directory) just delete it and build it again.
Trying to install a Python module called Dislin. Unfortunately I haven't had success setting the environment for Dislin, and I will get an install error. The instructions for setting the path are below, but they are a bit obscure to me. Can anyone make it a bit more explicit? (I'm learning).
d) Choose a directory in the file structure where DISLIN should be
installed and define the environment variable DISLIN with it:
For example: export DISLIN/$HOME/dislin
ftp://ftp.gwdg.de/pub/grafik/dislin/darwin/README.DARWIN
My site packages for python 2.7 are here: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages. I would assume I need to point Dislin home here, but so far have not been successful, as I am probably doing it wrong, but I get an error like: export: `DISLIN/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/dislin': not a valid identifier
If you've already installed dislin, what you have to do is make sure that wherever you've installed the data for dislin (not for Python), is on your system environmental variable PYTHONPATH. This is pointed out in #5 in the ftp link you posted.
What you would do, if dislin can be found on your computer at the path you posted above, is add the following to your PYTHONPATH:
DISLIN/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/dislin
I am trying to install some software on a Linux machine (python's rpy2 package, rpy2.robjects in particular, if it matters). I need the software to look for its shared libraries in my local space, not in the global spaces like /usr/lib64 whatever. I do not have admin privileges on this machine. My problem is that even though I set LD_LIBRARY_PATH to point to my local space, the software still goes to the /usr/lib64/whatever, where it finds libraries that are out of date. These libraries are missing some objects it needs, so it fails. What could be taking precedence over LD_LIBRARY_PATH, and is there a way to change/get rid of it? Thanks.
BTW, someone on this site had a similar question a year or more ago, but his answer involved the env variable RPATH, and changing it with the chrpath utility. It is not clear to me at all that rpy2 is using RPATH, and chrpath seems unavailable on my system.
Addendum: I tried running with LD_DEBUG=libs. Got alot of output that looks like the system is looking for the libs in my LD_LIBRARY_PATH and finding them. Here is where the trouble seems to start:
/usr/local/lib64/R/library/methods/libs/methods.so: error: symbol lookup error:
undefined symbol: Rf_allocS4Object (fatal)
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object '/usr/local/lib64/R/library/methods/libs/methods.so':
/usr/local/lib64/R/library/methods/libs/methods.so: undefined symbol: Rf_allocS4Object
So my guess is that the trouble is that whatever is in DLLpath is overriding LD_LIBRARY_PATH. I have tried to change this by prepending my directories to os.environ['PATH'], but no do. There is apparently no "DLLPATH", as I thought there would be.
OK, that's progress, I guess. Anybody have anything else? Thanks.
Have a look at a file named $R_HOME/etc/ldpaths (where in your case $R_HOME seems to be /usr/local/lib64/R). It is the commands in this file that set LD_LIBRARY_PATH at R's start-up.
Mine looks like this:
flodel#netbook-samsung-N150:~$ cat /usr/lib/R/etc/ldpaths
: ${JAVA_HOME=/usr/lib/jvm/java-6-openjdk/jre}
: ${R_JAVA_LD_LIBRARY_PATH=${JAVA_HOME}/lib/i386/client:${JAVA_HOME}/lib/i386:/usr/lib/jni}
if test -n ""; then
: ${R_LD_LIBRARY_PATH=${R_HOME}/lib:}
else
: ${R_LD_LIBRARY_PATH=${R_HOME}/lib}
fi
if test -n "${R_JAVA_LD_LIBRARY_PATH}"; then
R_LD_LIBRARY_PATH="${R_LD_LIBRARY_PATH}:${R_JAVA_LD_LIBRARY_PATH}"
fi
if test -z "${LD_LIBRARY_PATH}"; then
LD_LIBRARY_PATH="${R_LD_LIBRARY_PATH}"
else
LD_LIBRARY_PATH="${R_LD_LIBRARY_PATH}:${LD_LIBRARY_PATH}"
fi
export LD_LIBRARY_PATH
If you do not have write access to the file, you can still do this before starting R:
export R_LD_LIBRARY_PATH=/your/custom/path
I tested on my machine that it works by running the following after R is started:
Sys.getenv("LD_LIBRARY_PATH")
#[1] "/your/custom/path:/usr/lib/jvm/java-6-openjdk/jre/lib/i386/client:/usr/lib/jvm/java-6-openjdk/jre/lib/i386:/usr/lib/jni"
If anyone is still reading this, I engaged in some "personnel engineering" to solve the problem, i.e. got the system admins to re-install R so that it had everything I needed. Was certainly nice of them. Thanks very much to everyone who gave suggestions. Would like to keep going on some of them, but I've got to get busy on this project. Much obliged!
RPATH is only useful when compiling (well, linking); it affects the library search path that gets baked into the binary.
Try running with LD_DEBUG=libs, which will show libraries are being loaded from which paths. Is it trying to load from your LD_LIBRARY_PATH but failing, or not searching there in the first place (perhaps rpy2 has its own library path mechanism?), or something else?
Try adding your directory on the left of the LD_LIBRARY_PATH as the precedence goes left to right.
export LD_LIBRARY_PATH=~/your/custom/path:$LD_LIBRARY_PATH