I recently started to working on WSL Ubuntu-20.04. There is no problem on running the server. But when I tried to connect the Django Console of Pycharm, I get the error below:
Traceback (most recent call last):
File "<input>", line 7, in <module>
ModuleNotFoundError: No module named 'django_manage_shell'
I checked the consoles interpreter and starting script, tried to add project path, my virtualenv path but nothing worked.
My Django Console Options
This is starting script:
import sys; print('Python %s on %s' % (sys.version, sys.platform))
import django; print('Django %s' % django.get_version())
sys.path.extend([WORKING_DIR_AND_PYTHON_PATHS])
if 'setup' in dir(django): django.setup()
import django_manage_shell; django_manage_shell.run(PROJECT_ROOT)
I had no issues like this when I working on Ubuntu nor Windows. This issue happened with WSL.
So I'm waiting for your helps and thanks a lot for your time.
I'm not on WSL but this question came up when I was searching for a solution and Hassaan AlAnsary's answer helped me.
On Linux, running PyCharm 2022.2.1, with Python in Docker, I got this error and solved it by modifying the starting script in Settings -> Build, Execution, Deployment -> Console -> Django Console.
I took the line:
sys.path.extend([WORKING_DIR_AND_PYTHON_PATHS])
and I added the location of the helper in the Docker container:
sys.path.extend([WORKING_DIR_AND_PYTHON_PATHS, "/opt/.pycharm_helpers/pycharm"])
and this fixed the problem.
So, I have a terrible workaround for this, and I will leave it here for fellow travelers passing through this lonely part of StackOverflow. But I hope someone else can do better.
The django_manage_shell module is coming from PyCharm's helpers, and isn't part of the normal Django distribution. When running under WSL, these helpers are not accessible to the python interpreter, and you get the above error.
The best solution I was able to arrive at was to make the code in that helper module accessible in the startup script. Fortunately, you can get at this module (and the fix_getpass module it relies on) with only mild difficulty. The code for each can be found in these spots (depending on your PyCharm installation):
C:\Program Files\JetBrains\PyCharm 2021.2\plugins\python\helpers\pycharm\django_manage_shell.py
C:\Program Files\JetBrains\PyCharm 2021.2\plugins\python\helpers\pycharm\fix_getpass.py
I took the code I found in those modules, and pasted it into the Django Console startup script in PyCharm. I had to reorganize things a bit, and change the call django_manage_shell.run() to invoke the copied-over code instead.
I cannot stress how brittle and gross this approach is, but I haven't found an alternative. If I figure out a better approach, or if JetBrains fixes this on their own, I'll come back and update this answer.
EDIT: Slight improvement to my original solution, which involved a rogue python module on the WSL side. This avoids polluting your project, and constrains the hack to just the PyCharm side of things.
as #Nacho said, it is because PyCharm can't reach the helpers folder on Windows Host machine from within WSL.
You can add the path to the PyCharm helpers folder to your path mapping.
consequently, all the helper files will be reachable by pycharm
One way to do that is to:
Open Setting -> Build, Execution, Deployment -> Django Console
add new Path Mapping
local path
C:/Program Files/JetBrains/PyCharm 2021.3.3/plugins/python/helpers/pycharm
remote path
/mnt/c/Program Files/JetBrains/PyCharm 2021.3.3/plugins/python/helpers/pycharm
Close the console and open it again
modify the path above according to your PyCharm version and WSL setup
now PyCharm will be able to locate django_manage_shell and any other
Related
I am trying to debug some computer vision code (say dcgan) built on top of tensorflow. I installed the tf_0.10 in virtualenv (say, py1) and I use eclipse+pydev as the IDE. The problem is that the debugger can't find the cuda library so I get the error like the following,
ImportError: libcudart.so.8.0: cannot open shared object file: No such file or directory
On the other hand, the code works correctly on ubuntu command line and py1 in the virtualenv has no problem finding the cuda library.
In my eclipse+pydev setup, I set a py intepreter as py1,
by setting eclipse menu->window->preference->intepreters->python intepreter as
/home/zyuan/tensorflowr010/bin/python2.7 (where /home/zyuan/tensorflowr010 is the root of virtualenv)
Also the system PYTHONPATH for the above intepreter is,
/home/zyuan/tensorflowr010/lib/python2.7
/home/zyuan/tensorflowr010/lib/python2.7/lib-dynload
/home/zyuan/tensorflowr010/local/lib/python2.7/site-packages
/home/zyuan/tensorflowr010/lib/python2.7/site-packages
/home/zyuan/tensorflowr010/lib
Then I chose py1 and the intepreter for my computer vision code dcgan,
by setting dcgan -> properities -> pyDev-interpreter/grammer as py1 and add >external Librarie /usr/local/cuda/lib64 on pyDev-PYTHONPATH
Do I miss anything else?
Can you run it from the command line? If not, that'd be the first step, if you already can, my suggestion is starting Eclipse from that same shell and then checking if all environment variables when you launch it match the ones from the shell.
As a note, the PYTHONPATH is a special variable in PyDev made up from the files you add in the interpreter and in source folders in projects, so, to check the PYTHONPATH my suggestion is creating a program with:
import sys
print('\n'.join(sorted(sys.path)))
and run that from the command line and from inside Eclipse to compare what may be different (and fix the configuration on PyDev accordingly).
Also, after it works in the command-line, it may be nice launching Eclipse from that same shell (so that it will inherit all the env vars you defined in that shell, which may save you time from having to check many other env vars which may be important too).
I ran into a similar problem where my GPU was successfully accessed by tensorflow on the command line but not eclipse. I have 2 things to try to resolve this sitation.
Restart Eclipse - If changes have been made to the paths since you last opened eclipse, it may simply have a stale view of the environment
Within Runtime Configurations, set the necessary environment variables, in particular CUDA_PATH, to force location of the correct current path, especially if you may have multiple versions of CUDA lying around.
Your current status can be checked with:
import os
print(os.environ)
However, please note that in situation 1 where eclipse is stale, you may still get the correct environment variables printed out, even if eclipse is not aware of the current state of affairs.
I am using PyCharm 5 to run a Python 2.7 (Anaconda) script in Ubuntu. My script imports a module with import tensorflow, but this causes the error ImportError: libcudart.so.7.0: cannot open shared object file: No such file or directory. So, it seems that the library libcudart.so.7.0 is needed by this module, but it cannot be found.
Now, I have seen that this library is on my machine in /usr/local/cuda-7.0/targets/x86_64-linux/lib. So, in PyCharm, I went to Settings->Project Interpreters->Interpreter Paths. This had a list of paths, such as /home/karnivaurus/Libraries/Anaconda/python2.7. I then added to this list, the path mentioned above which contains the required library.
However, this did not fix the problem. I still get an error telling me that libcudart.so.7.0 cannot be found. If I run my script from the shell though (python myfile.py), then it runs fine.
How can I tell PyCharm where to find this library?
I have noticed that if I have print sys.path in my script, the paths it prints out are entirely different to those in Settings->Project Interpreters->Interpreter Paths... should they be the same?
I came across this problem just recently using a remote debugger, however I believe it's still the same solution. I just added the following to the Environment Variables section in the Run/Debug Configuration options found in Run > Edit Configurations... dialog: LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH
The path to your cuda library seems strange to me. I would expect it to be /usr/local/cuda-7.0/lib64 or /usr/local/cuda-7.0/lib.
Did you follow all of the cuda installation procedure?
If you type env on the command line, do you see a path to cuda in your LD_LIBRARY_PATH?
Update from comments below:
The issue is that PyCharm was invoked from the desktop, and wasn't getting the right environment variables. Solution is to either:
invoke from the command line,
create a script to set environment and then invoke, and make a link to that script on the desktop,
or set environment variables on the desktop item
While some of these answers are correct, and could work, I haven't seen what the OP specifically asked for, and that is where to set environments for the python console. This can be accomplished inside pycharm at:
File > Settings > Build,Execution,Deployment > Console > Python Console
In the options there, you'll find a place to define Environment Variables. Set LD_LIBRARY_PATH there.
Edit your pycharm.desktop, specify the environment variable in exec, like below:
[Desktop Entry]
Version=1.0
Type=Application
Name=Pycharm
Exec=env LD_LIBRARY_PATH=:/usr/local/cuda/lib64:/usr/local/cuda/lib64 /home/cwh/software/pycharm-2016.1.4/bin/pycharm.sh
Icon=/home/cwh/software/pycharm-2016.1.4/bin/pycharm.png
Name[zh_CN]=Pycharm
so pycharm will find cuda
Have you selected the right python interpreter in your project's settings?
See here.
I had a similar issue and changing the interpreter solved it without having to create a new icon.
The following works for me on Community edition 2019.3
To set globally for a project:
Open File/Settings/Project/Project Interpreter
click on the cog icon next to the interpreter
choose show all
click on the little folder with tree icon bottom right
add the path to "Interpreter Paths"
When I try to run any of my app engine projects by python GoogleAppEngineLauncher
I got the error log as follows:
Does anyone have any ideas of what's going on?
I tried remove the SDK and reinstall it. Nothing happens. Still got the same error.
Everything is working fine and I don't think I made any changes before this happens.
The only thing that I can think of is that I install bigquery command line tool before this happens. But I don't think this should be the reason of this.
bad runtime process port ['']
Traceback (most recent call last):
File
"/Users/txzhang/Documents/App/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/_python_runtime.py",
line 197, in
_run_file(file, globals()) File "/Users/txzhang/Documents/App/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/_python_runtime.py",
line 193, in _run_file
execfile(script_path, globals_) File "/Users/txzhang/Documents/App/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/devappserver2/python/runtime.py",
line 175, in
main() File "/Users/txzhang/Documents/App/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/devappserver2/python/runtime.py",
line 153, in main
sandbox.enable_sandbox(config) File "/Users/txzhang/Documents/App/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/devappserver2/python/sandbox.py",
line 159, in enable_sandbox
import('%s.threading' % dist27.name) File "/Users/txzhang/Documents/App/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/devappserver2/python/sandbox.py",
line 903, in load_module
raise ImportError('No module named %s' % fullname) ImportError: No module named google.appengine.dist27.threading
The most probable reason is having another python package that is coming from google. Run
python in verbose mode with python -vvvvv and try following command import google.
If the above import is successful make sure its coming from /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google which is the path of python google appengine libraries on my system (OSX, fresh install of google appengine sdk).
If that is not the case (but the import is successful) then its most likely other existing google libraries which are creating issue and the path of the same would be visible on python prompt after the successful import google command like following:
>>> import google
import google # loaded from Zip
/Library/Python/2.7/site-packages/protobuf-2.4.1-py2.7.egg/google/init.pyc
In this case my google protobuf package was the culprit.
Solution:
Use virtualenv: If you haven't used python virtualenv before, may be this is the best time to use it. (a) Make sure that your PYTHONPATH variable is not set to include anything that has a google package! Unset it running unset PYTHONPATH (in your bash prompt) unless you are very sure what you have there. (b) Create a new python virtualenv, activate it and try to run google appengine commands in it:
virtualenv --no-site-packages /tmp/googleapps
source /tmp/googleapps/bin/activate
dev_appserver.py path_to_google_app
Remove conflicting packages from path: Move conflicting packages a new virtualenv. This is likely to break other stuff so not recommended.
I had hit the same issue today. This being the top result on google but lacked any answers, I add this after fixing same issue on my system. There may be other possible reasons which thankfully I haven't come across.
Good luck!
A recent upgrade of the development SDK started causing this problem for me. After much turmoil, I found that the problem was that the SDK was in a sub-directory of my project code. When I ran the SDK from a different (parent) directory the error went away.
I have a pydev project going in aptana studio 3.
In the image below, you can see my project structure and the fact that my nosetests are all passing.
If I click on a file scheduled.py that has a breakpoint in it, and hit debug as > python run it fails to be able to import my modules.
pydev debugger: starting
Traceback (most recent call last):
File "C:\Users\mapserv\AppData\Local\Aptana Studio 3\plugins\org.python.pydev_2.7.0.2012110722\pysrc\pydevd.py", line 1397, in <module>
debugger.run(setup['file'], None, None)
File "C:\Users\mapserv\AppData\Local\Aptana Studio 3\plugins\org.python.pydev_2.7.0.2012110722\pysrc\pydevd.py", line 1090, in run
pydev_imports.execfile(file, globals, locals) #execute the script
File "C:\Users\mapserv\Desktop\Projects\Aptana\AutomatedCaching\agrc\caching\scheduled.py", line 1, in <module>
from agrc.caching.commands import cache
ImportError: No module named agrc.caching.commands
I've noticed that aptana has the notion of packages/modules. Is there something wrong with my project structure that is causing this? Should my folders be packages? Do I need to setup more things with my interpreter which looks like?
Edited
If I try to run scheduled.py from the command line it has the same problem. How is nose running my tests and making everything happy yet it doesn't work outside of that?
Well the answer was to update your PYTHONPATH. On windows, put the path to the AutomatedCaching folder inside the automated_caching.pth file.
eg: C:\Projects\AutomatedCaching
Then move the file into your site packages folder. For arcgis users it will be something like
C:\Python27\ArcGISx6410.1\Lib\site-packages
or
C:\Python27\ArcGIS10.1\Lib\site-packages
depending if you installed server and desktop. I'm thinking the last install wins the PATH war? I installed server then desktop and it uses the second in the path without the x64.
running
import sys
for i in sys.path:
print i
should verify that your location has been added.
Now the fact that arcgis for server and desktop install two different pythons into c:\python27 is a whole different story.
Now aptana shows my package explorer like it is a package
Did you try putting it in your "PyDev - PYTHONPATH" project properties? Project -> Properties -> PyDev - PYTHONPATH -> Source Folders(tab) -> Add source folder.
Then you don't have to mess with your system PYTHONPATH.
It worked for me.
Tried to post an image but I guess I don't have enough reputation points.
Im developing an installer for a GNU/Linux distribution in Python using Eclipse+PyDev. For some tasks on it there is needed that the program runs with root priviledges, but I run Eclipse as a common user.
I had searched a lot of stuff on the Internet about how to run an app as root without having to run Eclipse with priviledges, but no a single clue of how to accomplish this in a "nice way". So I tried with the "gksu2" python module, with has the gksu2.sudo() functions in the same way as gksu in bash.
I created a new module, imported gksu2 and executed the main.py module of the app, but I got a "ImportError: No module named ui.regular_ui.wizard". It runs ok without gksu2 in eclipse, but it doesn't if I use it. I thought it was an environment variables problem, but the sys.path is ok.
The same error happens if I run the app from a terminal, outside of Eclipse. What do you think?
It seems like your PYTHONPATH is different outside/inside Eclipse. Try just removing the Python interpreter and adding it again to gather new paths -- if that's not enough, do: import sys;print('\n'.join(sorted(sys.path))) outside/inside Eclipse to know what's different and fix your paths inside Eclipse.