I can open an interactive shell from the command line, just not from PyDev inside Eclipse. Clicking through Django --> Shell with django environment I get the following output:
import sys; print('%s %s' % (sys.executable or sys.platform, sys.version))
C:\Python27\python.exe 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)]
PyDev console: using default backend (IPython not available).
from django.core import management;import carbon_factors.settings as settings;management.setup_environ(settings)
Traceback (most recent call last):
File "<console>", line 1, in <module>
AttributeError: 'module' object has no attribute 'setup_environ'
To try and resolve this I have updated PyDev to 3.2.0 with no change to the output. I'm using Django 1.6.
I have looked at the comment here which pointed me here. However the accepted answer seems to have already be built into Django/PyDev as the line it suggests to change in manage.py is already changed.
setup_environ has been deprecated in Django 1.6. See here.
As far as I can tell, PyDev has hardcoded this method of starting a Django shell into the right click project -> "shell with Django environment" menu item. This is an issue that PyDev needs to address (hopefully by simplifying whatever they are doing under the hood with that command to just "python manage.py shell"!) I don't believe their menu command currently calls manage.py, which is why the other answers didn't work for you.
Option 1
As a hacky workaround, add "from django.conf import settings; settings.configure()" to the initial interpreter commands in Window->Preferences->PyDev->Interactive Console. You'll still see the error but at least you'll have your settings.
Option 2
In Window->Preferences->Interpreter->Environment tab, add an environment variable "DJANGO_SETTINGS_MODULE" with the Python dotted path to your settings file (exclude the '.py' at the end).
For the sake of having an up-to-date answer, this works fine for me with Django 1.8 and Eclipse Luna.
For Django 1.10 and Eclipse Neon.
Following Option 1 from andy.
My settings file is inside myproject/config/settings/local.py.
Go to: Window->Preferences->PyDev->Interactive Console->Initial Commands
and replace the first line with:
import os; os.environ['DJANGO_SETTINGS_MODULE'] = 'config.settings.local'; import django
if '1.10' in django.get_version():
django.setup()
Related
Anaconda:1.8.3
VScode: 1.22.2
Mac: 10.13.4
Just upgraded to Anaconda 1.8.3 and now cannot access Django packages.
from the conda python environment prompt I get:
Last login: Sun Apr 29 19:21:31 on ttys001
/Users/bill/.anaconda/navigator/a.tool ; exit;
Bills-iMac:~ bill$ /Users/bill/.anaconda/navigator/a.tool ; exit;
Python 3.6.4 |Anaconda, Inc.| (default, Jan 16 2018, 12:04:33)
[GCC 4.2.1 Compatible Clang 4.0.1 (tags/RELEASE_401/final)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>> django.VERSION
(2, 0, 2, 'final', 0)
>>>
So I know that Django is installed and can be imported from the terminal. From within the VSCode integrated terminal I get:
Bills-iMac:Prov bill$ python manage.py makemigrations
Traceback (most recent call last):
File "manage.py", line 8, in <module>
from django.core.management import execute_from_command_line
ModuleNotFoundError: No module named 'django'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "manage.py", line 14, in <module>
) from exc
ImportError: Couldn't import Django. Are you sure it's installed and available on your PYTHONPATH environment variable? Did you forget to activate a virtual environment?
Bills-iMac:Prov bill$
Within the VSCode Settings my python.pythonPath hasn't changed - it is still:
{
"python.pythonPath": "/anaconda3/envs/py36"
}
Within the venv the path is:
>>> import sys
>>> print(sys.path)
['', '/anaconda3/envs/py36/lib/python36.zip', '/anaconda3/envs/py36/lib/python3.6', '/anaconda3/envs/py36/lib/python3.6/lib-dynload', '/anaconda3/envs/py36/lib/python3.6/site-packages']
>>>
I've updating the settings in VScode to the sys.path above - but that didn't change anything. I know that the package is installed and I know I can get to in from the prompt, but I can't get VScode to work. If it is a path issue, I'm not sure how to fix it - I'm guessing it is something more - just not sure what.
Update
I just realized that if I change the pythonPath in VScode settings that the pylint in VScode throws an error - it can not find the Django packages. That tells me that somehow the VScode has the right settings to resolve the paths - but is still unable to import the packages when the program is run from the integrated terminal. I can also run python manage.py for makemigrations, migrate and runserver from the venv terminal (outside of VScode) - now I'm less sure as to what the problem is but it seems to be specific to the VScode integrated terminal.
I hit a similar program just now with Django on Windows and found this document: https://code.visualstudio.com/docs/python/tutorial-django
As part of this, it recommends setting your Python Interpreter to your virtual environment:
View->Command Palette... or just Ctrl-Shift-P
Python: Select Interpreter
Choose the one corresponding to your virtual environment
That fixed my lookup errors as well as actions in the terminal, so perhaps something similar would work.
I have an annoying problem with PyCharm CE and naoqi. Following the installation instructions in Aldebaran Guide, I have configured my environment to work with this one.
I have installed the version of python (python 2.7.13) suggested by Aldebaran, I have written the .bash_profile using:
# Setting PATH for Python 2.7
# The original version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}"
export PATH
#NaoQI 2.5.5
export PYTHONPATH=${PYTHONPATH}:/Users/francesco/Documents/PyLibs/pynaoqi-python2.7-2.5.5.5-mac64/lib/python2.7/site-packages
export DYLD_LIBRARY_PATH=${DYLD_LIBRARY_PATH}:/Users/francesco/Documents/PyLibs/pynaoqi-python2.7-2.5.5.5-mac64/lib
after that, I launch my code in python from Terminal (making sure that the right version of python is called when I type
$ python my_code.py
and all is working (I tried also with virtualenv and all works fine if I launch all from terminal).
So far so good but then comes the poison arrow. I use PyCharm CE like IDE, I have created a new project that use the same environment that works fine in terminal and the magic happens..
The first issue is:
/Users/francesco/Documents/PyEnv/pynaoqi255_python2713/bin/python /Users/francesco/PycharmProjects/PepperRobot/PepperRobot.py
Traceback (most recent call last):
File "/Users/francesco/PycharmProjects/PepperRobot/PepperRobot.py", line 5, in
import qi
ImportError: No module named qi
(Ok seriuosly this is the same environment that in terminal works)
I try to bypass the problem, adding the content of naoqi sdk in the virtualenv's site-package. Ok, the problem is bypassed.. But there is another problem:
/Users/francesco/Documents/PyEnv/pynaoqi255_python2713/bin/python /Users/francesco/PycharmProjects/PepperRobot/PepperRobot.py
Traceback (most recent call last):
File "/Users/francesco/PycharmProjects/PepperRobot/PepperRobot.py", line 5, in
import qi
File "/Users/francesco/Documents/PyEnv/pynaoqi255_python2713/lib/python2.7/site-packages/qi/init.py", line 88, in
from _qi import Application as _Application
ImportError: dlopen(/Users/francesco/Documents/PyEnv/pynaoqi255_python2713/lib/python2.7/site-packages/_qi.so, 2): Library not loaded: #loader_path/libqipython.dylib
Referenced from: /Users/francesco/Documents/PyEnv/pynaoqi255_python2713/lib/python2.7/site-packages/_qi.so
Reason: image not found
Process finished with exit code 1
I did not understand why...
I have also include in
Preferences -> console -> Python Console -> Environment Variables
the same variables included in .bash_profile but to no avail.
How can I solve this tedious problem ?
I have solved my problem editing run/debug configuration and putting here the environment variable DYLD_LIBRARY_PATH. All works fine.
I'm trying to run a populate script which I put together from the tango_with_django tutorial (https://github.com/leifos/tango_with_django/blob/master/tango_with_django_project/populate_rango.py) however I'm getting the below traceback and it seems to be related to changes made in Django 1.7? I'd appreciate if someone could explain what I'm doing wrong here.
(test_env) C:\Users\WriteCode\test_env\epl>python populate_clubs.py
Traceback (most recent call last):
File "populate_clubs.py", line 4, in <module>
django.setup()
File "c:\Python27\lib\site-packages\django\__init__.py", line 20, in setup
configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)
File "c:\Python27\lib\site-packages\django\conf\__init__.py", line 46, in __ge
tattr__
self._setup(name)
File "c:\Python27\lib\site-packages\django\conf\__init__.py", line 40, in _set
up
% (desc, ENVIRONMENT_VARIABLE))
django.core.exceptions.ImproperlyConfigured: Requested setting LOGGING_CONFIG, b
ut settings are not configured. You must either define the environment variable
DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings.
(test_env) C:\Users\WriteCode\test_env\epl>
My populate_clubs.py script
import os
import sys
import django
django.setup()
def add_club(name, nickname, manager, established, stadium, active=True):
c = clubs.objects.get_or_create(name=name, nickname=nickname, manager=manager, established=established, stadium=stadium, active=active)
return c
def populate():
add_club(name = "Aston Villa",
nickname = "Villans",
manager = "Tim Sherwood",
established = "1897",
stadium = "Villa Park"
)
# Print out what was added
for c in clubs.objects.all():
print "The following has been added to clubs:" + c
# Start execution
if __name__ == '__main__':
print "Starting club population script..."
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'epl.settings')
from teams.models import clubs
populate()
You can insert os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings") before the django.setup() line.
Call to django.setup() should go after setting DJANGO_SETTINGS_MODULE environment variable. Just move it into your __main__ right after os.environ.setdefault().
If you are getting a similar error after initiating your interaction with Django by running python in a terminal, running python manage.py shell in the appropriate directory may solve your issue.
For development and debugging, you may use the standalone python package.
Install with pip
pip install standalone
Use standalone to use Django from the module.
# add the following to the top of the module.
import standalone
standalone.run('mysite.settings') # replace with your settings module.
# your code goes below the configuration
import os
import sys
# ... .. . whole module
Now you may run the module as a Python Django script.
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'epl.settings')
should be above
import django
which is you should call django_settings_module before importing and calling django setup.
Hope this is helpful.
If you're running PyCharm, what worked for me was to invalidate the cache and restart the app.
File => Invalidate Caches / Restart ...
My virtualenv had been recently updated from Python 3.6 or 3.7 to 3.8.
It happened to me when I used django related import statement in a non-django module.
i.e from index.views import view that did raise an error for me.
I met the same problem when setting the environment.
(I tried to add the:
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "my_project.settings")
into the "Starting script window",which is in the Django Console or rewrite the .wsgi file, But all of them were failed)
My final solution: (open the terminal and set the environment manually)
Here are the steps:(for mac)
open the terminal and type vim ~/.bash_profile
add below lines:
PATH=${PATH}:/Users/work/workspace/[virtual_environment]/bin
PYTHONPATH=${PATH}:/Users/work/PycharmProjects/[project_name]
DJANGO_SETTINGS_MODULE=[project_name].settings
type :wq to save and exit terminal
type source ~/.bash_profile to reload it
it will work when you run python manage.py shell this time.
Make sure to activate your venv first by scripts/activate venv then in your populate_user.py right after import os run os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'epl.settings') this should work.
I've just cloned a Django project using Mercurial to a Windows machine that I have set up Python 2.7 on. When I try to run manage.py (with or without a command), I get the following error:
Traceback (most recent call last):
File "C:\Users\jes.000\Documents\project\manage.py", line 30, in <module>
import django.core.servers.basehttp
File "C:\Python27\lib\site-packages\django\core\servers\basehttp.py", line 26, in <module>
from django.views import static
File "C:\Python27\lib\site-packages\django\views\static.py", line 95, in <module>
template_translatable = ugettext_noop(u"Index of %(directory)s")
File "C:\Python27\lib\site-packages\django\utils\translation\__init__.py", line 75, in gettext_noop
return _trans.gettext_noop(message)
File "C:\Python27\lib\site-packages\django\utils\translation\__init__.py", line 48, in __getattr__
if settings.USE_I18N:
File "C:\Python27\lib\site-packages\django\utils\functional.py", line 184, in inner
self._setup()
File "C:\Python27\lib\site-packages\django\conf\__init__.py", line 40, in _setup
raise ImportError("Settings cannot be imported, because environment variable %s is undefined." %ENVIRONMENT_VARIABLE)
ImportError: Settings cannot be imported, because environment variable DJANGO_SETTINGS_MODULE is undefined.
I understand that manage.py is supposed to set that environment variable. I also understand that I might be getting this error because the project is not in the python path... but adding it manually seems like it shouldn't be necessary. Isn't manage.py supposed to resolve this issue as well?
Edit: I've just tested and found that it does the exact same thing under Linux.
Edit: Here's a useful discovery: I only get this error if I install Django via PIP, it works fine if I install the python-django package on Ubuntu. So there's something that the debian package is doing that PIP isn't. Maybe the debian package sets some environment variables? I need to figure that out, since I'm trying to develop on Windows.
Edit: I think I've found the problem, but not a solution. Working on an Ubuntu machine, when I install Django via PIP (pip install django), this project doesn't work with the error I gave. If I create a new project (django-admin startproject testproject) and try that it works, and it consists of manage.py in the created folder, with another folder that contains everything else. Like this:
+-testproject
+-manage.py
+-testproject
+-__init__.py
+-etc.
When I install the Debian package (apt-get install python-django) the project I'm trying to work on works, and if I create a test project (django-admin startproject testproject) it has a folder structure like this:
+-testproject
+-manage.py
+-__init__.py
+-etc.
Notice the difference: the PIP Django package seems to put the manage.py outside of the python module that is the app, while the Debian package puts manage.py inside the module. I assume that this is due to the two packages being of a different version of Django, in between which they changed the structure, because the two packages doing this differently doesn't make any sense.
So my problem is that the project I'm trying to develop was originally generated using the version that's been Debian packaged, while on my Windows machine I'm trying to use the version of Django from pip.
The trouble is that I'm not certain how to fix the problem. Naively moving the manage.py up a directory so it's above the project folder doesn't work, because this 'debian-package version' manage.py tries to just import settings, which fails if it's not in the same folder as settings.py. But somewhere else in Django, something seems to be expecting the project itself to be at //settings.py (as would be the case if the pip version of django-admin was used) rather than at /settings.py (as is the case if the debian-package version is used).
If I look it up, the version in the Ubuntu repositories is 1.3.1, while the version in PyPI is 1.4. Look at the release notes for 1.4, and hey:
An updated default project layout and manage.py that removes the
“magic” from prior versions. And for those who don’t like the new
layout, you can use custom project and app templates instead!
But... shouldn't projects generated with the 1.3 layout still work under 1.4..?
I'm not sure if this has changed in more recent version of django, but the default manage.py simply tries to import the settings.py file and start the manager. You would be expected to put the project in your PYTHONPATH, or to put the settings.py into your DJANGO_SETTINGS_MODULE variable, by default.
You can modify the manage.py to be a bit smarter with this snippet:
manage.py
#!/usr/bin/env python
from django.core.management import execute_manager
...
import settings
import os
project = os.path.basename(os.path.dirname(__file__))
os.environ['DJANGO_SETTINGS_MODULE'] = '%s.settings' % project
if __name__ == "__main__":
execute_manager(settings)
Now you can run manage.py from any location, since it will always explicitly set up the path to the settings.py file.
You may add the following code to the file manage.py ,like this:
from django.conf import settings
settings.configure()
This is indeed due to the difference in default layouts between 1.3 and 1.4. Normally Django 1.3 projects will work under 1.4, so something else is going on here that I can't quite figure out. I have established that the problem isn't platform-dependent.
I couldn't figure out the exact problem but I did figure out a fix. That was:
Create a new project under Django 1.4 and poach its manage.py file. After changing the project name, this file works as a manage.py. I named it 'manage14.py' so that the original manage.py would be left for my colleagues using Django 1.3.
Add the directory above the one that the project was in to the global PYTHONPATH. This is not an ideal solution, but it allowed an unmodified Django 1.4 manage.py to load the project without having to convert the project to Django 1.4's organization.
As soon a practical, I plan to convert the project to the Django 1.4 format since it seems to be better anyway, particularly from the perspective of avoiding this kind of problem. Unfortunately I'll have to wait until the Ubuntu repo's get 1.4 so that my colleagues will be up to the same version I am on Windows using PyPI.
I'm trying to run a custom django command as a scheduled task on Heroku. I am able to execute the custom command locally via: python manage.py send_daily_email. (note: I do NOT have any problems with the custom management command itself)
However, Heroku is giving me the following exception when trying to "Run" the task through Heroku Scheduler addon:
Traceback (most recent call last):
File "bin/send_daily_visit_email.py", line 2, in <module>
from django.conf import settings
ImportError: No module named django.conf
I placed a python script in /bin/send_daily_email.py, and it is the following:
#! /usr/bin/python
from django.conf import settings
settings.configure()
from django.core import management
management.call_command('send_daily_email') #delegates off to custom command
Within Heroku, however, I am able to run heroku run bin/python - launch the python shell - and successfully import settings from django.conf
I am pretty sure it has something to do with my PYTHON_PATH or visibility to Django's SETTINGS_MODULE, but I'm unsure how to resolve the issue. Could someone point me in the right direction? Is there an easier way to accomplish what I'm trying to do here?
Thank you so much for your tips and advice in advance! New to Heroku! :)
EDIT:
Per Nix's comment, I made some adjustments, and did discover that specifying my exact python path, I did get past the Django setup.
I now receive:
File "/app/lib/python2.7/site-packages/django/core/management/__init__.py", line 155, in call_command
raise CommandError("Unknown command: %r" % name)
django.core.management.base.CommandError: Unknown command: 'send_daily_email'
Although, I can see 'send_daily_email' when I run ``heroku run bin/python app/manage.py```.
I'll keep an update if I come across the answer.
You are probably using a different interpreter.
Check to make sure shell python is the same as the one you reference in your script /usr/bin/python . It could be that there is a different one in your path, which would explain why it works when you run python manage.py but not your shell scrip which you explicitly reference /usr/bin/python.
Typing which python will tell you what interpreter is being found on your path.
In addition, this can also be resolved by adding your home directory to your Python path. A quick and unobtrusive way to accomplish that is to add it to the PYTHONPATH environment variable (which is generally /app on the Heroku Cedar stack).
Add it via the heroku config command:
$ heroku config:add PYTHONPATH=/app
That should do it! For more details: http://tomatohater.com/2012/01/17/custom-django-management-commands-on-heroku/