ImportError: No module named django, sys.path fine - python

I'm trying to configure Django with
python manage.py shell
And I get the error:
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/lib64/python2.7/site-packages/django/core/management/__init__.py", line 367, in execute_from_command_line
utility.execute()
File "/usr/lib64/python2.7/site-packages/django/core/management/__init__.py", line 341, in execute
django.setup()
File "/usr/lib64/python2.7/site-packages/django/__init__.py", line 27, in setup
apps.populate(settings.INSTALLED_APPS)
File "/usr/lib64/python2.7/site-packages/django/apps/registry.py", line 85, in populate
app_config = AppConfig.create(entry)
File "/usr/lib64/python2.7/site-packages/django/apps/config.py", line 123, in create
import_module(entry)
File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
ImportError: No module named django
I've seen a lot of questions about this error, and most of them seem to be centered on the fact that django's path is not included in python's sys.path. Mine is, however. When I run
sudo pip install django
I get
Requirement already satisfied: django in /usr/lib64/python2.7/site-packages
And the output for my sys.path is
['', '/usr/lib64/python27.zip', '/usr/lib64/python2.7', '/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk', '/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload', '/usr/lib64/python2.7/site-packages', '/usr/lib64/python2.7/site-packages/gtk-2.0', '/usr/lib/python2.7/site-packages']
So the path is absolutely there.
What are my options here? This is a remote interpreter using SSH from Pycharm, and it's seriously delaying my work.

If which python, when run by the normal user, returns ~/bin/python, then this is a different Python from the one run by the superuser, which, according to what you say, is /bin/python. sudo pip install django runs as the superuser and installs Django in the system's Python environment. When, afterwards, you execute python manage.py shell, it runs another Python, and that other Python's environment apparently doesn't have Django installed.
If you run pip install django without the sudo it might work, but since you have superuser permission on that machine it would be better to get rid of the Python installation that you have in the normal user's home directory, and make sure your system has only one Python installation until you really know what you are doing. Otherwise you will be confused whether you use virtualenv or not.
Edit: I disagree with many comments that tell you to use virtualenv. You are confused enough without it. Let's simplify the problem first. Remove all virtualenvs you have created (you do this by deleting the directories) and forget everything about virtualenv. Logout and login again (this will ensure the virtualenvs are deactivated). Don't modify your manage.py, it's fine as it was originally. Install Django system-wide with sudo pip install django, then try to run your Django project with python manage.py shell. Only after you get it working and you start having a grip on the system go on to start playing with virtualenv. Virtualenv is great, but everything in its time. (virtualenv demystified is an introduction to virtualenv written by me.)

Related

importlib.metadata.PackageNotFoundError: No package metadata was found for djoser pyinstaller

Context
I made a Django react app. Now I want to make it a desktop application so that the user does not have type python manage.py runserver and also activate the environment every time. I used pyinstaller. I did all the steps mentioned for django.
Problem
when I run my executable file made from pyinstaller, I got this error
File "manage.py", line 5, in <module>
File "PyInstaller\loader\pyimod02_importers.py", line 499, in exec_module
File "djoser\__init__.py", line 6, in <module>
File "importlib\metadata\__init__.py", line 955, in version
File "importlib\metadata\__init__.py", line 928, in distribution
File "importlib\metadata\__init__.py", line 518, in from_name
importlib.metadata.PackageNotFoundError: No package metadata was found for djoser
[2200] Failed to execute script 'manage' due to unhandled exception!
What I have done
I have already installed Djoser in the environment and the environment is also activated. I have also tried to add in manage.py file and also in hidden_import lists but nothing changed. I have also tried adding --copy-meta=djoser in the build command but it got even worse error.
How do I fix this error and If there are any better alternative solutions out there? Thanks
Well I have found for myself another solution . To run this django file by creating a batch file
#echo off
set "VENV_NAME=myenv"
set "PROJECT_DIR=C:\path\to\project"
cd /d %~dp0
cd /d %PROJECT_DIR%
call "%VENV_NAME%\Scripts\activate.bat"
python manage.py runserver
manage.exe runserver --norelaod

Syntax Error When Trying to Open Downloaded Django Application

I am trying to work on a Django application that I downloaded from bitbucket which uses Python2-based code. Previously, Python 3.6 and Django 2.0 was on my system, so I downgraded to Python 2.7 and Django 1.11 to try to get it to work.
When I go to the project directory and type in "python manage.py runserver," I get a syntax error (this is a shortened version of it, hence the dots):
Unhandled exception in thread started by <function wrapper at 0x0000000006A0A358>
Traceback (most recent call last):
File "C:\Users\M\Anaconda3\lib\site-packages\django\utils\autoreload.py", line 227, in wrapper
fn(*args, **kwargs)
.
.
.
File "C:\Users\M\Anaconda3\lib\site-packages\django\contrib\admindocs\urls.py", line 2, in <module>
from django.contrib.admindocs import views
File "C:\Users\M\Anaconda3\lib\site-packages\django\contrib\admindocs\views.py", line 9, in <module>
from django.contrib.admindocs import utils
File "C:\Users\M\Anaconda3\lib\site-packages\django\contrib\admindocs\utils.py", line 12, in <module>
import docutils.core
File "C:\Users\M\Anaconda3\lib\site-packages\docutils\core.py", line 246
print('\n::: Runtime settings:', file=self._stderr)
^
SyntaxError: invalid syntax
If you have a solution to this problem, please let me know.
As said by #emi, you want to use virtualenv. It's a great tool that allows you to create an isolated virtual environment for each Python project. Each virtual environment can have its own version of every dependency.
On Windows, I recommend using it alongside virtualenvwrapper, witch is is just a very thin wrapper with some higher level commands.
It seems your Python installation is broken so uninstall every version of Python you have, reinstall Python 2 and follow along creating a virtualenv for your project (and for every new one you start). If you need you can install Python 3 in the future as well without messing with you previous envs.

Is it possible to use the python3 bindings for VirtualBox?

I am trying to use the python 3 bindings to VirtualBox but there appears to be broken dependencies. It seems odd to me that this hasn't been fixed over the ~4 years that people have been having this issue. Perhaps I'm missing something obvious. It's been known to happen.
I have installed the virtualbox host modules, sdk, and extensions through my OS's pacakage manager. Then, through pip:
pip install pyvbox
The imports work:
from virtualbox import VirtualBox, Session, Manager, WebServiceManager
But then any attempt to instantiate anything results in an exception complaining about a missing vboxapi.
box = VirtualBox()
Traceback:
Traceback (most recent call last):
File "<input>", line 1, in <module>
File "/usr/lib/python3.6/site-packages/virtualbox/library_ext/vbox.py", line 22, in __init__
manager = virtualbox.Manager()
File "/usr/lib/python3.6/site-packages/virtualbox/__init__.py", line 130, in __init__
with import_vboxapi() as vboxapi:
File "/usr/lib/python3.6/contextlib.py", line 82, in __enter__
return next(self.gen)
File "/usr/lib/python3.6/site-packages/virtualbox/__init__.py", line 45, in import_vboxapi
import vboxapi
File "/home/$USER/.eclipse/org.eclipse.platform_4.6.3_155965261_linux_gtk_x86_64/plugins/org.python.pydev_5.7.0.201704111357/pysrc/_pydev_bundle/pydev_import_hook.py", line 20, in do_import
module = self._system_import(name, *args, **kwargs)
ModuleNotFoundError: No module named 'vboxapi'
There is a vboxapi on PyPi, but it won't install as there is no code associated with it, nor any useful information on the PyPi page:
https://pypi.python.org/pypi/vboxapi
Here are a couple links to the valiant efforts of braver souls than I. It is not immediately clear to me which is the correct solution or if either are still relevant, given that they are from 3 and 4 years ago, respectively.
https://github.com/GreatFruitOmsk/vboxapi-py3
https://github.com/jbuergel/vboxapi-py3
Also from 3 years ago, word of a vboxapi.diff and intergration into vboxapi:
https://www.virtualbox.org/pipermail/vbox-dev/2014-April/012231.html
I'm the current maintainer of the pyvbox package.
The VirtualBox SDK already supports Python 3, I use Python 3.5 to develop the library. I recommend uninstalling and reinstalling the latest version of the SDK (which at the time of writing this is 5.1.22).
You can find the SDK on the VirtualBox downloads page. Unzip the archive and run the vboxapisetup.py file using your system Python with the following command:
python vboxapisetup.py install
You don't need to install this in any virtualenv, as pyvbox will search your system libraries in addition to virtualenv installations for better ease of use.
If you have problems using the pyvbox package after running these steps, please open an issue and include as much information as possible including the steps you took, OS, where your system Python is located, which version of VirtualBox & SDK you're using, and I'll help you as best I can.
Yes you can, it is possible, very tricky to setup but it work fine for me now (Ubuntu 18.04 / python3.6 / virtualbox 6.0) .
The error:
ModuleNotFoundError: No module named 'vboxapi'
mean that python3 does not find vboxapi module, now there is two methods to "force-install" the vboxapi package to python3:
First Method [easy]: Assuming pyvbox is already installed and work fine with python2.7, in that case you can simply copy the package from python2.7 dist-packages to python3 dist-package with:
sudo cp -r /usr/lib/python2.7/dist-packages/vboxapi /usr/lib/python3/dist-packages
Second method [more tricky]: Go to VirtualBox, then download the last Software Developer Kit (SDK), actually the 6.0.4
Unzip the archive and run the vboxapisetup.py file using Python3 with the following command:
sudo python3 vboxapisetup.py install
You will get this issue:
Traceback (most recent call last):
File "vboxapisetup.py", line 90, in <module>
main(sys.argv)
File "vboxapisetup.py", line 63, in main
raise Exception("No VBOX_INSTALL_PATH defined, exiting")
Exception: No VBOX_INSTALL_PATH defined, exiting
You may directly edit the current file vboxapisetup.py and replace line 57, from vboxDest = os.environ.get("VBOX_MSI_INSTALL_PATH", None) to vboxDest = "/usr/lib/virtualbox"
Then run agin:
sudo python3 vboxapisetup.py install
And now you will get something like that:
running install
running build
running build_py
copying vboxapi/__init__.py -> build/lib/vboxapi
running install_lib
creating /usr/local/lib/python3.6/dist-packages/vboxapi
copying build/lib/vboxapi/__init__.py -> /usr/local/lib/python3.6/dist-packages/vboxapi
copying build/lib/vboxapi/VirtualBox_constants.py -> /usr/local/lib/python3.6/dist-packages/vboxapi
byte-compiling /usr/local/lib/python3.6/dist-packages/vboxapi/__init__.py to __init__.cpython-36.pyc
byte-compiling /usr/local/lib/python3.6/dist-packages/vboxapi/VirtualBox_constants.py to VirtualBox_constants.cpython-36.pyc
running install_egg_info
Removing /usr/local/lib/python3.6/dist-packages/vboxapi-1.0.egg-info
Writing /usr/local/lib/python3.6/dist-packages/vboxapi-1.0.egg-info
which mean that we are ok with vboxapi package installation !
Now, let's try again to load virtualbox() inside python3:
from virtualbox import VirtualBox, Session, Manager, WebServiceManager
box = VirtualBox()
this probably will raise this new issue:
Traceback (most recent call last):
File "virtualbox_python3_test.py", line XX, in <module>
vbox = virtualbox.VirtualBox()
File "/usr/local/lib/python3.6/dist-packages/virtualbox/library_ext/vbox.py", line 22, in __init__
manager = virtualbox.Manager()
File "/usr/local/lib/python3.6/dist-packages/virtualbox/__init__.py", line 143, in __init__
self.manager = vboxapi.VirtualBoxManager(mtype, mparams)
File "/usr/local/lib/python3.6/dist-packages/vboxapi/__init__.py", line 989, in __init__
self.platform = PlatformXPCOM(dPlatformParams)
File "/usr/local/lib/python3.6/dist-packages/vboxapi/__init__.py", line 750, in __init__
import xpcom.vboxxpcom
File "/usr/lib/virtualbox/sdk/bindings/xpcom/python/xpcom/vboxxpcom.py", line 78, in <module>
raise Exception('Cannot find VBoxPython module (tried: %s)' % (', '.join(_asVBoxPythons),))
Exception: Cannot find VBoxPython module (tried: VBoxPython3_6m, VBoxPython3m, VBoxPython)
If you dig you will find a lot of questions (question 1,question 2,question 3, question 4 etc...) relative to this issue on the web ...
But according to my dig & research, if you are lucky (and have a Virtualbox built with python3 native support) you can try:
cd /usr/lib/virtualbox/
sudo cp VBoxPython3_5m.so VBoxPython3_6m.so
But if you got the following error:
cp: cannot stat 'VBoxPython3_5m.so': No such file or directory
It mean that you don't have native python3 support in Virtualbox...
This could be solved like this:
Go here and download the python3-virtualbox-5.2.16 binary package (we don't care about the VirtualBox version...)
Now open python3-virtualbox-5.2.16-lp150.4.11.1.x86_64.rpm archive, browse it to /./usr/lib/virtualbox/, then extract the file VBoxPython3_6m.so, then drop this file in your current working directory, after that from this directory you have to do:
sudo cp VBoxPython3_6m.so /usr/lib/virtualbox/
And now, you can use python3 binding for virtualbox !

Pycharm: Run manage task won't work if path contains space

I'm running Pycharm 2.6.3 with python 2.7 and django 1.5.1. When I try to run django's manage.py task from Pycharm (Tools / Run manage.py task), syncdb, for instance, I get the following:
bash -cl "/usr/bin/python2.7 /home/paulo/bin/pycharm-2.6.3/helpers/pycharm/django_manage.py syncdb /home/paulo/Projetos/repo2/Paulo Brito/phl"
Traceback (most recent call last):
File "/home/paulo/bin/pycharm-2.6.3/helpers/pycharm/django_manage.py", line 21, in <module>
run_module(manage_file, None, '__main__', True)
File "/usr/lib/python2.7/runpy.py", line 170, in run_module
mod_name, loader, code, fname = _get_module_details(mod_name)
File "/usr/lib/python2.7/runpy.py", line 103, in _get_module_details
raise ImportError("No module named %s" % mod_name)
ImportError: No module named manage
Process finished with exit code 1
If I run the first line on the console passing project path between single quotes, it runs without problems, like this:
bash -cl "/usr/bin/python2.7 /home/paulo/bin/pycharm-2.6.3/helpers/pycharm/django_manage.py syncdb '/home/paulo/Projetos/repo2/Paulo Brito/phl'"
I tried to format the path like that in project settings / django support, but Pycharm won't recognize the path.
How can I work in PyCharm with paths with spaces?
Thanks.
EDIT 1
PyCharm dont recognize path with baskslash as valid path either.
it's known bug http://youtrack.jetbrains.com/issue/PY-8449
Fixed in PyCharm 2.7
In UNIX you can escape whitespaces with a backslash:
/home/paulo/Projetos/repo2/Paulo\ Brito/phl
I had the same problem on ubuntu 18.4 LTS pycharm 2019.2.6.
I was trying to create a basic Django new project in folder 'Learing Django api' (my folder name had spaces in it). when I tried to run the server I got a error saying settings module not defined.
After spending few hours I realized pycharm was creating a seperate folder named 'Learning' in same directory.
I renamed my folder 'Learing Django api' to 'Learing_Django_api' and it worked.
I like pycharm but this folder insensitivity is insane.
Is it possible that you are taking in the argument with a space in it into a variable, then passing that to something that is seeing two arguments instead of one? If so, "requote" it before passing it along. Will you hit a point where that can't be corrected? If so, maybe the upgrade makes sense.

How to use virtualenv with Google App Engine SDK on Mac OS X 10.6

I am pulling my hair out trying to figure this out because I had it working until last week and somehow it broke.
When I setup a virtualenv for a Google App Engine app and start the app with dev_appserver.py, I get errors importing the standard library (like "ImportError: No module named base64").
Here's what I'm doing:
(Using the system Python)
virtualenv --python=python2.5 --no-site-packages ~/.virtualenv/foobar
Then I add the a gae.pth file to ~/.virtualenv/foobar/lib/python2.5/site-packages/ containing the Google App Engine libraries:
/usr/local/google_appengine
/usr/local/google_appengine/lib/antlr3
/usr/local/google_appengine/lib/cacerts
/usr/local/google_appengine/lib/django
/usr/local/google_appengine/lib/fancy_urllib
/usr/local/google_appengine/lib/ipaddr
/usr/local/google_appengine/lib/webob_1_1_1
/usr/local/google_appengine/lib/yaml/lib
(That's based on this answer.)
Then I source my "foobar" virtualenv and try to start my app with dev_appserver.py.
The server starts but the first request errors out with the aforementioned "ImportError: No module named base64". If I visit the admin console I get "ImportError: No module named cgi".
If I start up python, I can load these modules.
>>> import base64
>>> base64.__file__
'/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/base64.py'
It seems that the SDK's sandboxing is preventing these libraries from getting loaded. But like I said, I had this working until last week...something changed or I inadvertently broke my virtualenv and I can't figure out how I got it working in the first place.
Software versions:
Google App Engine SDK 1.3.7
Mac OS X Snow Leopard 10.6.4
virtualenv 1.5.1
Update: In response to Alan Franzoni's questions:
I am using the system Python that came with Mac OS X. I installed virtualenv via easy_install. I upgraded to virtualenv 1.5.1 today to try to fix the problem.
If I run python /usr/local/bin/dev_appserver.py with the virtualenv python, the problem persists. If I deactivate the virtualenv and run that command with the system python2.5, it works. (Also, I can use the GoogleAppEngineLauncher to start my app.)
Here is a full stack trace (this one uses the Kay framework, but the problem is the same with webapp):
Traceback (most recent call last):
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py", line 3206, in _HandleRequest
self._Dispatch(dispatcher, self.rfile, outfile, env_dict)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py", line 3149, in _Dispatch
base_env_dict=env_dict)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py", line 525, in Dispatch
base_env_dict=base_env_dict)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py", line 2402, in Dispatch
self._module_dict)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py", line 2312, in ExecuteCGI
reset_modules = exec_script(handler_path, cgi_path, hook)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py", line 2208, in ExecuteOrImportScript
exec module_code in script_module.__dict__
File "/Users/look/myapp/kay/main.py", line 17, in <module>
kay.setup()
File "/Users/look/myapp/kay/__init__.py", line 122, in setup
from google.appengine.ext import db
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py", line 1287, in Decorate
return func(self, *args, **kwargs)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py", line 1937, in load_module
return self.FindAndLoadModule(submodule, fullname, search_path)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py", line 1287, in Decorate
return func(self, *args, **kwargs)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py", line 1839, in FindAndLoadModule
description)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py", line 1287, in Decorate
return func(self, *args, **kwargs)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver.py", line 1790, in LoadModuleRestricted
description)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/ext/db/__init__.py", line 81, in <module>
import base64
ImportError: No module named base64
It's an issue 4339 with the GAE SDK, it's confirmed and there are two slightly different patches available in the bug entry that make it work.
What happens is dev_appserver.py sets up a restricted python environment by disallowing access to any non-system-python modules and it does that by calculating the system python folder from the location of the os module. In a virtualenv instance the os.py gets symlinked into the virtualenv but gets compiled straight into virtualenv, and this is the path that dev_appserver uses, effectively blocking access to any module from the system python library that is not linked by virtualend, which is most of them. The solution is to "bless" both paths.
Google AppEngine SDK makes a lot of trick in order to pull its install into sys.path, and these tricks rely on actual file's path. I think there might be a lot of various reasons why it fails. SDK doesn't install itself as a real python package, virtualenv doesn't do complete sandboxing, it just sets up an environment (obviously) and changes sys.path. And GAE SDK does this too, they both intefere, SDK is being developing rapidly and changing often, so this is extremely bumpy road to go.
Probably, it would be better if you'd explain what are you trying to achieve. My guess is that you're trying to create a clean environment to ensure that no 3rd-party module is available to application. If this guess is correct, I'd go with installing GAE SDK into virtualenv via requirements files as described here.
I think, since you've setup virtualenv with the --no-site-packages option, you need to install the SDK into the environment. --no-site-packages seperates the dev environment you're configuring from any other Python installation on your computer so, as you seem to have it configured you're calling a module that doesn't exist (in the environment) which is why it works with the env deactivated (which is then running Python from the default OS installation). Try setting up the dev env without the --no-site-packages option if you want to be able to access modules outside of the env.
I'm a little late to the conversation, but I was just having the same issue and I stumbled across gae_installer, which you can install in the usual way with pip install gae_installer. This will put the google app engine (gae) sdk directly into your python path. Hope others find this useful.
Same answer as bozzo. Here's instructions:
This is described in Issue 4339 for GAE. Here's how to fix it:
Download patch here: patch
Move the patch to google_appengine/google/appengine/tools/
Change your working directory to the same path as above
Type: patch -p0 < dev_appserver.patch

Categories