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.
I want to run JdeRobot drone_cat_mouse on my Ubuntu 20.04. I'm using ROS Noetic and has faithfully followed these installation instructions. Everything it told me to test was working properly.
When I first ran roslaunch drone_cat_mouse.launch, there was an import error for teleopWidget and sensorsWidget which I fixed by using relative imports. Then I had an error No module named qfi.
Unlike teleopWidget and sensorsWidget, I couldn't find the qfi module in the JdeRobot/drones source code. So I googled it, and the only relevant result that popped up was this, which led to this link. They said to:
sudo touch /usr/lib/python2.7/dist-packages/qfi/__init__.py
But I ran that command and this happened!
Not even pip has a "qfi" module!
So I thought to check JdeRobot's entire repository. Turns out it was in JdeRobot/base, and that repo is not maintained anymore!
After further digging, there was this issue which basically tells us forget about it and move to the web release! But I can't, circumstances forced me to use the source code option (deliverables are drone_cat_mouse.world and my_solution.py, it's impossible for me to get the former in the docker web version and the latter's format is different between the source code version and the web version).
In a nutshell, how do I fix this qfi module problem so that I can run the exercises from source like these people?
I'm just stupid, as usual. all I need to do was clone https://github.com/JdeRobot/ThirdParty, get the qfi module, copy it to
~/catkin_ws/src/drones/rqt_drone_teleop/src/rqt_vel_teleop/ and replace all qfi imports with its relative import version. All common sense
No errors in terminal, gazebo runs, but somehow the rqt widget for drone vision never appears.
Forget it, I'm giving up on this dumpster fire of a program.
Edit: I did another fresh install, followed the steps, noticed troubleshooting for qfi which required qmake, but same end result
If you're trying to launch drone_cat_mouse there is an issue with the namespace of the RQT widget that occurs when you try to launch it.
Namely, the topics that exist for drone_cat_mouse are prefixed by cat/ or mouse/. But RQT will try to access these topics without the prefix and run into an error. Alternatively, since you have a local install, you can try to run the code manually by running
python my_solution.py
Just make sure the change the area where the DroneWrapper class was called in the following manner:
HAL = DroneWrapper('drone', 'cat/')
Here 'drone' is the name of the node you are creating and 'cat/' is the namespace given to the DroneWrapper Class.
I am attempting to put together a simple c++ test project that uses an embedded python 3.2 interpreter. The project builds fine but Py_Initialize raises a fatal error:
Fatal Python error: Py_Initialize: unable to load the file system codec
LookupError: no codec search functions registered: can't find encoding
Minimal code:
#include <Python.h>
int main (int, char**)
{
Py_Initialize ();
Py_Finalize ();
return 0;
}
The OS is 32bit Vista.
The python version used is a python 3.2 debug build, built from sources using VC++ 10.
The python_d.exe file from the same build runs without any problems.
Could someone explain the problem and how to fix it? My own google-fu fails me.
EDIT 1
After going through the python source code I've found that, as the error says, no codec search functions have been registered. Both codec_register and PyCodec_Register are as they should be. It's just that nowhere in the code are any of these functions called.
I don't really know what this means as I still have no idea when and from where these functions should have been called. The code that raises the error is entirely missing from the source of my other python build (3.1.3).
EDIT 2
Answered my own question below.
Check the PYTHONPATH and PYTHONHOME environment variables and make sure they don't point to Python 2.x.
http://bugs.python.org/issue11288
Parts of this have been mentioned before, but in a nutshell this is what worked for my environment where I have multiple Python installs and my global OS environment set-up to point to a different install than the one I attempt to work with when encountering the problem.
Make sure your (local or global) environment is fully set-up to point to the install you aim to work with, e.g. you have two (or more) installs of, let's say a python27 and python33 (sorry these are windows paths but the following should be valid for equivalent UNIX-style paths just as well, please let me know about anything I'm missing here (probably the DLLs path might differ)):
C:\python27_x86
C:\python33_x64
Now, if you intend to work with your python33 install but your global environment is pointing to python27, make sure you update your environment as such (while PATH and PYTHONHOME may be optional (e.g. if you temporarily work in a local shell)):
PATH="C:\python33_x64;%PATH%"
PYTHONPATH="C:\python33_x64\DLLs;C:\python33_x64\Lib;C:\python33_x64\Lib\site-packages"
PYTHONHOME=C:\python33_x64
Note, that you might need/want to append any other library paths to your PYTHONPATH if required by your development environment, but having your DLLs, Lib and site-packages properly set-up is of prime importance.
Hope this helps.
The core reason is quite simple: Python does not find its modules directory, so it can of course not load encodings, too
Python doc on embedding says "Py_Initialize() calculates the module search path based upon its best guess" ... "In particular, it looks for a directory named lib/pythonX.Y"
Yet, if the modules are installed in (just) lib - relative to the python binary - above guess is wrong.
Although docs says that PYTHONHOME and PYTHONPATH are regarded, we observed that this was not the case; their actual presence or content was completely irrelevant.
The only thing that had an effect was a call to Py_SetPath() with e.g. [path-to]\lib as argument before Py_Initialize().
Sure this is only an option for an embedding scenario where one has direct access and control over the code; with a ready-made solution, special steps may be necessary to solve the issue.
Ran into the same thing trying to install brew's python3 under Mac OS! The issue here is that in Mac OS, homebrew puts the "real" python a whole layer deeper than you think. You would think from the homebrew output that
$ echo $PYTHONHOME
/usr/local/Cellar/python3/3.6.2/
$ echo $PYTHONPATH
/usr/local/Cellar/python3/3.6.2/bin
would be correct, but invoking $PYTHONPATH/python3 immediately crashes with the abort 6 "can't find encodings." This is because although that $PYTHONHOME looks like a complete installation, having a bin, lib etc, it is NOT the actual Python, which is in a Mac OS "Framework". Do this:
PYTHONHOME=/usr/local/Cellar/python3/3.x.y/Frameworks/Python.framework/Versions/3.x
PYTHONPATH=$PYTHONHOME/bin
(substituting version numbers as appropriate) and it will work fine.
From python3k, the startup need the encodings module, which can be found in PYTHONHOME\Lib directory.
In fact, the API Py_Initialize () do the init and import the encodings module.
Make sure PYTHONHOME\Lib is in sys.path and check the encodings module is there.
I had this issue with python 3.5, anaconda 3, windows 7 32 bit. I solved it by moving my pythonX.lib and pythonX.dll files into my working directory and calling
Py_SetPythonHome(L"C:\\Path\\To\\My\\Python\\Installation");
before initialize so that it could find the headers that it needed, where my path was to "...\Anaconda3\". The extra step of calling Py_SetPythonHome was required for me or else I'd end up getting other strange errors where python import files.
I just ran into the exact same problem (same Python version, OS, code, etc).
You just have to copy Python's Lib/ directory in your program's working directory ( on VC it's the directory where the .vcproj is )
There appears to be something going wrong with the release build either failing to include the appropriate codecs or else misidentifying the codec to use for system APIs. Since the python_d executable is working, what does that return for os.getfsencoding()? (Use the C API to call that between your Initialize/Finalize calls)
I had the same issue and found this question. However from the answers here I was not able to solve my problem. I started debugging the cpython code and thought that I might be discovered a bug. Therefore I opened a issue on the python issue tracker.
My mistake was that I did not understand that Py_SetPath clears all inferred paths.
So one needs to set all paths when calling this function.
Link to the issue conversation
For completion I also copied the most important part of the conversation below.
My original issue text
I compiled the source of CPython 3.7.3 myself on Windows with Visual Studio 2017 together with some packages like e.g numpy. When I start the Python Interpreter I am able to import and use numpy. However when I am running the same script via the C-API I get an ModuleNotFoundError.
So the first thing I did, was to check if numpy is in my site-packages directory and indeed there is a folder named numpy-1.16.2-py3.7-win-amd64.egg. (Makes sense because the python interpreter can find numpy)
The next thing I did was to get some information about the sys.path variable created when running the script via the C-API.
#### sys.path content ####
C:\Work\build\product\python37.zip
C:\Work\build\product\DLLs
C:\Work\build\product\lib
C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2017\PROFESSIONAL\COMMON7\IDE\EXTENSIONS\TESTPLATFORM
C:\Users\rvq\AppData\Roaming\Python\Python37\site-packages
Examining the content of sys.path I noticed two things.
C:\Work\build\product\python37.zip has the correct path 'C:\Work\build\product\'. There was just no zip file. All my files and directory were unpacked. So I zipped the files to an archive named python37.zip and this resolved the import error.
C:\Users\rvq\AppData\Roaming\Python\Python37\site-packages is wrong it should be C:\Work\build\product\Lib\site-packages but I dont know how this wrong path is created.
The next thing I tried was to use Py_SetPath(L"C:/Work/build/product/Lib/site-packages") before calling Py_Initialize(). This led to
Fatal Python Error 'unable to load the file system encoding'
ModuleNotFoundError: No module named 'encodings'
I created a minimal c++ project with exact these two calls and started to debug Cpython.
int main()
{
Py_SetPath(L"C:/Work/build/product/Lib/site-packages");
Py_Initialize();
}
I tracked the call of Py_Initialize() down to the call of
static int
zipimport_zipimporter___init___impl(ZipImporter *self, PyObject *path)
inside of zipimport.c
The comment above this function states the following:
Create a new zipimporter instance. 'archivepath' must be a path-like
object to a zipfile, or to a specific path inside a zipfile. For
example, it can be '/tmp/myimport.zip', or
'/tmp/myimport.zip/mydirectory', if mydirectory is a valid directory
inside the archive. 'ZipImportError' is raised if 'archivepath'
doesn't point to a valid Zip archive. The 'archive' attribute of the
zipimporter object contains the name of the zipfile targeted.
So for me it seems that the C-API expects the path set with Py_SetPath to be a path to a zipfile. Is this expected behaviour or is it a bug?
If it is not a bug is there a way to changes this so that it can also detect directories?
PS: The ModuleNotFoundError did not occur for me when using Python 3.5.2+, which was the version I used in my project before. I also checked if I had set any PYTHONHOME or PYTHONPATH environment variables but I did not see one of them on my system.
Answer
This is probably a documentation failure more than anything else. We're in the middle of redesigning initialization though, so it's good timing to contribute this feedback.
The short answer is that you need to make sure Python can find the Lib/encodings directory, typically by putting the standard library in sys.path. Py_SetPath clears all inferred paths, so you need to specify all the places Python should look. (The rules for where Python looks automatically are complicated and vary by platform, which is something I'm keen to fix.)
Paths that don't exist are okay, and that's the zip file. You can choose to put the stdlib into a zip, and it will be found automatically if you name it the default path, but you can also leave it unzipped and reference the directory.
A full walk through on embedding is more than I'm prepared to type on my phone. Hopefully that's enough to get you going for now.
I had the problem and was tinkering with different solutions mentioned here. Since I was running my project from Visual Studio, apparently, I needed to set the environment path inside Visual Studio and not the system path.
Adding a simple PYTHONHOME=PATH\TO\PYTHON\DIR in the project solution\properties\environment solved the problem.
For me this happened when I updated Python 64 bit from 3.6.4 to 3.6.5. It threw some error like "unable to extract python.dll. Do you have permissions."
Pycharm also failed to load interpreter, even though I reloaded it in settings. Running python command gave same error, with and without administrator mode.
Reason
There was error in installation of Python, include folder in python installation directory C:\Users\USERNAME\AppData\Local\Programs\Python\Python36 was missing
Reinstalling Python also dint solve the issue.(Not removal and install)
Solution
Uninstall Python and Install of Python again.
Because running installer was just extracting same files excluding include folder
In my cases, for windows, if you have multiple python versions installed, if PYTHONPATH is pointing to one version the other ones didn't work. I found that if you just remove PYTHONPATH, they all work fine
For those working in Visual Studio simply add the include, Lib and libs directories to the Include Directories and Library Directories under
Projects Properties -> Configuration Properties > VC++ Directories :
For example I have Anaconda3 on my system and working with Visual Studio 2015 This is how the settings looks like (note the Include and Library directories) :
Edit:
As also pointed out by bossi setting PYTHONPATH in your user Environment Variables section seems necessary.
a sample input can be like this (in my case):
C:\Users\Master\Anaconda3\Lib;C:\Users\Master\Anaconda3\libs;C:\Users\Master\Anaconda3\Lib\site-packages;C:\Users\Master\Anaconda3\DLLs
is necessary it seems.
Also, you need to restart Visual Studio after you set up the PYTHONPATH in your user Environment Variables for the changes to take effect.
Also note that :
Make sure the PYTHONHOME environment variable is set to the Python
interpreter you want to use. The C++ projects in Visual Studio rely on
this variable to locate files such as python.h, which are used when
creating a Python extension.
So, for some reason the python dll fails to locate the encodings module. The python.exe executable apparently finds it because it has the expected relative path. Modifying the search path works.
The reason for all of this? Don't know but at least it works. I highly suspect a typo on my part somewhere, that's usually the reason for odd bugs it seems.
I want to use the rpy2 package. When I import R's PortfolioAnalytics library which does not belong to the standard library, I do not get any output anymore. (I run my python code directly from Idle on Windows and not via the Windows console (because of the problem I outlined below).)
Examples:
First code works fine:
import rpy2.robjects as robjects
from rpy2.robjects.packages import importr
print 'check output 1'
utils = importr("utils") # 'utils' belongs to the standard lib
print 'check output 2'
Output:
check output 1
check output 2
So far so good. But in the following example it will not work anymore.
Second code does not work:
import rpy2.robjects as robjects
from rpy2.robjects.packages import importr
print 'check output 1'
utils = importr("PortfolioAnalytics", lib_loc = "C:\username\Documents\R\win-library\3.3")
print 'check output 2'
Output:
check output 1
Additional note:
I am not sure whether the following is connected to the problem: When I want to execute my code using the Windows Console , I get the error
RuntimeError: R_USER not defined.
(I have added R's bin directory to the PATH variable.) Anyways, that is not my urgent problem. I only wanted to add this information in case it might be connected to my problem.
This should be a comment, but I can't write comments yet.
I tried to reproduce your error, which I couldn't. Here are my thoughts:
During installation of R on Windows I was forced to set R_USER. I don't know how you got around that, but I think it is a good idea to do so.
There are different versions of R available. The newest one (R 3.3.0) does store the R.dll in the directory specified in this post, which is were R_HOME supposedly should point to. I have seen at other places people using higher directories (.../R/R-x.y.z/) or different directories (.../R/R-x.y.z/bin/i386). If it causes problems, you might want to try one of those.
It also seems to be a good idea to add the directory containing the R.dll to your PATH variable.
The last thing I can think of concerns your usage of lib_loc. While the documentation of rpy2 states, that this option to importrshould point to the library, the CRAN page of Portfolio Analytics states, that the package has to be compiled. Unlikely as it may be, could it be that your package is not installed via (for instance) install.packages("PortfolioAnalytics"), or at least not correctly? In that case your lib_loc value might point to the correct directory, but the library is not actually compiled.
Approximately what I did:
Install R
Install Python
Download and install the visual c++ compiler for python
Set the R_HOME and R_USER environment variables and add the directory containing R.dll to my PATH.
Use the R command line to install PortfolioAnalytics (and all its dependencies) with install.packages("package_name") taking into account the accepted answer from here.
After that, running your code worked for me without errors. (Tested from command line, IDLE and Eclipse (PyDev) on Windows 10 with Python 2.7 and R 3.3.0.)
If this doesn't help you, maybe you can share some more information on what you have tried so far.
Edit: I was able to partly reproduce the described behavior and it seems to be related to the usage of lib_loc. There seems to be no detailed documentation for importr and also not for the usage of lib_loc. After making sure that the package was installed correctly, I tried to specify its location with the lib_loc argument. The following directories all turned out to be invalid values for this purpose:
/R_DIR/library
/R_DIR/library/PortfolioAnalytics
/R_DIR/library/PortfolioAnalytics/libs
/R_DIR/library/PortfolioAnalytics/libs/x64
/R_DIR/library/PortfolioAnalytics/libs/i386
That's all I checked. However, I am fairly sure, that installing the package into /R_DIR/library (which works best, if R is not installed in any system directory like Program Files, due to Windows restrictions) should make it unnecessary to specify lib_loc. If I am correct, that is a viable workaround, especially if you are just starting to set up your R environment.
Actually a different issue and already explained here has occurred during the importr command (I think) at some point. As explained in the link this is related to the missing ls function in Windows and solved for me by Preet Kukreti's answer.
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.