I read the django doc and some SO posts to know the differences between manage.py and django-admin.py.
They all say:
manage.py is automatically created in each Django project. manage.py
is a thin wrapper around django-admin.py that takes care of two things
for you before delegating to django-admin.py:
It puts your project’s package on sys.path.
It sets the DJANGO_SETTINGS_MODULE environment variable so that it points to
your project’s settings.py file.
So I checked the scource code of these 2 files(latest version, so it the doc).
Then I am confused. manage.py does the second thing: sets the DJANGO_SETTINGS_MODULE environment variable. Besides that, I really can not find any differences between these 2 scripts.
[django-admin.py]
#!/usr/bin/env python
from django.core import management
if __name__ == "__main__":
management.execute_from_command_line()
[manage.py]
#!/usr/bin/env python
import os
import sys
if __name__ == "__main__":
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings")
from django.core.management import execute_from_command_line
execute_from_command_line(sys.argv)
Why? Is the django documentation out of date? Or I missed something here? And where is the code that puts the project’s package on sys.path?
The sys.path is updated here using handle_default_options(options) statement located here. The execution path is as follows:
execute_from_command_line(argv) (your manage.py)
utility.execute() here
handle_default_options(options) here
The same method is used by Command class used as base class for management commands.
From what I can see it's not ./manage.py who "puts your project’s package on sys.path."
The doc says:
sys.path is initialized from these locations:
The directory containing the input script (or the current directory when no file is specified).
PYTHONPATH (a list of directory names, with the same syntax as the shell variable PATH).
The installation-dependent default.
The installation-dependent default must be what site.py adds. But it can be disabled with -S switch. Now then when I run this script (1.py):
import sys
print(sys.path)
I get:
$ python -S ../1.py # to show that it's not current directory that is added
['/path/to/the/script/directory', '/usr/lib/python35.zip', '/usr/lib/python3.5/', \
'/usr/lib/python3.5/plat-linux', '/usr/lib/python3.5/lib-dynload']
So, when you run django-admin, /path/to/env/bin/django-admin will be the first on the sys.path. And when ./manage.py, /path/to/project.
As such, one can probably say that ./manage.py "puts your project’s package on sys.path," but indirectly, by being at the root of your project.
Related
How can I permanently set the environmental variable DJANGO_SETTINGS_MODULE on WINDOWS on a permanent basis and be done with it?
I mean
Win Button + Pause/Break Button
This leads to Control Panel\System and Security\System
Click Advanced System Settings
Click Environment Variables
There are two boxes the first is titled User variables and the second System variables
On the System variables click the New Button
For variable name put in DJANGO_IMPORT_SETTINGS
XXX--> WHAT DO I PUT IN VARIABLE VALUE TO SET IT ONCE AND FOR ALL?
In the Django Site on this issue it states:
DJANGO_SETTINGS_MODULE
When you use Django, you have to tell it which settings you’re using. Do this by using an environment variable, DJANGO_SETTINGS_MODULE.
The value of DJANGO_SETTINGS_MODULE should be in Python path syntax,e.g. mysite.settings. Note that the settings module should be on the Python import search path.
What does it mean ...should be in Python path syntax e.g. mysite.settings... ?
I have a certain directory where my Python is located:
C:\Python27
I have a certain directory where my Django is located: C:\Python27\Lib\site-packages\django
What does this mysite means. What directory is it meanning C:\Something......
Can you put this variable once and for all or you have to constantly change it for every project (I hope not!)
And what does this suspiciously line means Note that the settings module should be on the Python import search path.
All I want it to set the DJANGO_SETTINGS_MODULE environmental variable and be done once and for all from this hassle
EDIT
In order to work, Django just has to be pointed at a valid settings file, and by default it
looks for an environment variable named DJANGO_SETTINGS_MODULE to tell it where to find the
settings. The value of this variable should be the Python import path of the settings file, such
as cms.settings.
--> What king of directory is this: cms.settings? In windows every directory starts with a hard drive as C:\Something...... How can you start a directory like this in Windows?
EDIT_2
Excerpt from a book
PROBLEM
Environment variable DJANGO_SETTINGS_MODULE is undefined.
SOLUTION
Run the command python manage.py shell rather than python.
MY QUESTION --> ON WHAT DIRECTORY?///CAN YOU SET IT FOR ONCE OR IS IT DIFFERENT PER PROJECT?
MY PROJECT IS STRUCTURED LIKE THIS
C:\Python27\pysec-master(file)
|__local_settings.py
|__manage.py
|__settings.py
|__C:\Python27\pysec(file)
|__ __init__.py
|__example.py
|__models.py
|__xbrl.py
|__xbrl_fundamentals.py
I am trying to run models.py and I have a settings.py in the C:\Python27\pysec-master
You can find an exact copy here.
MAYBE_IMPORTANT_EDIT
I have a file called manage.py in my project which has these contents
#!/usr/bin/env python
import os
import sys
if __name__ == "__main__":
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "settings")
from django.core.management import execute_from_command_line
execute_from_command_line(sys.argv)
Does this has to do anything on setting the variable? Do I need to set here here inside the loop?
EDIT
For the command in the IDLE from django.db import settings do i need to set a directory for the PYTHON_MODULE_SETTINGS like C:\Python27\Lib\site-packages\django\db ?
Okay, don't be so frustrated. Let's look at this step by step:
Python path syntax:
In Python, when you split your code base across modules, you qualify the name of the import with the name of the module. Let's say your project is structured like this:
my_project
|__utils
| |____init__.py
| |__file_utils.py
|__my_module
|____init__.py
|__main.py
In your main.py if you want to access methods you have defined in file_utils.py you add an import statement in your main.py like this:
import utils.file_utils.read_file
assuming read_file is the method you want to import into main.py. This way of importing modules where you have a . separating every module is referred as python path syntax.
PYTHONPATH:
In the above example, the import statement would work only if the Python interpreter knows where to look for the first module namely the utils. Only when it finds utils can it find file_utils and read_file. You specify the list of all the paths you want the interpreter to look into in the environment variable PYTHONPATH. So in order to have an import statement like above in your code, you have to make sure that the full path to your project my_project is in PYTHONPATH. Assuming my_project is in C:\AMAZEBALLS_CODE\my_project you should have C:\AMAZEBALLS_CODE in your PYTHONPATH
DJANGO_SETTINGS_MODULE:
Now let's suppose your my_project is actually a Django application. A Django application needs a settings file where you specify a whole bunch of things. In order to instruct Django which settings file to look into you specify it in DJANGO_SETTINGS_MODULE. Assuming this is your project structure:
my_project
|__utils/
| |____init__.py
| |__file_utils.py
|__my_module/
| |____init__.py
| |__main.py
|__site_settings/
|__dev_settings.py
|__production_settings.py
myroject.site_settings is the module Django has to look into for the settings file. And myroject.site_settings.dev_settings is the value you need to be setting to the DJANGO_SETTINGS_MODULE in the above case. When documentation says cms.settings or mysite.settings they mean cms or mysite is the name of your project and settings.py is the name of your settings file.
Now let's look at your question:
Can you permanently set it in the environment variables of Windows? Sure.
Is it the right way? No.
Because if you want to create another application tomorrow in another location, you will have to edit this in the environment variables section of Windows. Also, it is a practice to use a different settings file for development environment and another one for production. So setting it at one place with one value makes it inflexible. But if you are aware of all of the above and sure you are gonna be using just the one settings file set DJANGO_SETTINGS_MODULE to myproject.site_settings.dev_settings in the env variables section.
Hope this helps!
EDIT:
Looks like you are putting your pysec-master project in C:\Python27. Do not put your projects in the python installation. Create a settings.py file in your project and set DJANGO_SETTINGS_MODULE to pysec-master.settings
You said:
All i want it to set the DJANGO_SETTINGS_MODULE environmental variable
and be done once and for all from this hassle
If you don't want to go through a tedious procedure every time, you don't have to make it permanent, you only need to make the procedure automatic.
Create a bat and put set DJANGO_SETTINGS_MODULE='xxx.settings' inside.
If you are using virtualenv, you can set the environment variable in bin/activate.bat.
I have a project called "myplanet" and my manage.py file looks like:
#!/usr/bin/env python
import os
import sys
if __name__ == "__main__":
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myplanet.settings")
from django.core.management import execute_from_command_line
execute_from_command_line(sys.argv)
I know that I have to set a system variable DJANGO_SETTINGS_MODULE:myplanet.settings and also set the PYTHONPATH to my settings.py file. I was wondering what I should do in the case of another project that is called gMaps ? I tried to do the same but it does not simply work. My OS is Windows 7 x64
You can set up two independent virtual environments for each project. It's best practice I think. In that case you can even install different versions of python packages for each project as it required.
You can read about using virtualenv and it's wrapper here:
http://virtualenvwrapper.readthedocs.org/en/latest/index.html
You don't need to set PYTHONPATH variable environment to your django project for running that, when your settings.py is inside a package or is a module that is importable with manage.py.
The PYTHONPATH is a list of directories Python goes through to search for modules and files.
If you need to add a path of one library or your root path of project to it, you can do that in your code.
For example in manage.py with:
import sys
sys.path.append("/home/my/project")
Or:
import os
BASE_PATH = os.path.abspath(os.path.dirname(__file__))
sys.path.append(BASE_PATH + '/src/folder/of/my/project/')
And each django project has own manage.py file that set DJANGO_SETTINGS_MODULE enivoronment itself, and you don't need to set that.
I think if your manage.py have this line:
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myplanet.settings")
Then, you just need to have this structure for your project:
myplanet # It's a project folder
myplanet # It's a package
__init__.py
settings.py
manage.py
And you can run your project with python manage.py runserver without set PYTHONPATH environment variable.
I have recently started working with a settings directory as described in the Two Scoops of Django book. It contains the following files
local.py
staging.py
production.py
test.py
__init__.py
To be able to use the different setting files on the server I have adapted my django.fcgi script to import the settings module. It works very smoothly.
How do I do the same on my local machine on which I use runserver, however? I have set the DJANGO_SETTINGS_MODULE and I have adapted the manage.py file to
#!/usr/bin/env python
from django.core.management import execute_manager
import imp
import sys
sys.path.insert(0, '/home/user/don.joey/projects/a_project/a_project_site/settings')
import settings
try:
imp.find_module('settings') # Assumed to be in the same directory.
except ImportError:
import sys
sys.stderr.write("Error: Can't find the file 'settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n" % __file__)
sys.exit(1)
if __name__ == "__main__":
execute_manager(settings)
It works fine.
How can I make django-admin.py find these settings? I do not want to manually edit django-admin.py because it is part of my virtualenv and it will does thus regularly be updated.
Update
I have set the following: export DJANGO_SETTINGS_MODULE=settings.local.
You need to set two things
DJANGO_SETTINGS_MODULE and
PYTHONPATH so that the settings module can be found
The way Two Scoops of Django suggests setting up a project named blah you would have the following directory structure:
- blah_project/
- blah/
- manage.py
- blah/
- ...
- settings/
- __init__.py
- local.py
- production.py
- ...
Run the following (assuming a bash environment):
export DJANGO_SETTINGS_MODULE=blah.settings.local
export PYTHONPATH=/full/path/to/blah_project/blah
As long as django-admin.py is on your path (and it should be if django is installed and activated within your venv), you should be able to run:
django-admin.py runserver
I have a settings.py file and a dev_settings.py file that I use to override some values for dev purposes. Everytime I run the ./manage.py command, I have to specify --settings=whatever.local_settings. This becomes very tedious to do every time and I am trying to find a way to force manage.py to load my dev_settings.py file every by default so that I don't have to type that long argument every time I want to run a command.
I have tried setting DJANGO_SETTINGS_MODULE, however, it appears that manage.py overrides this option.
Is it possible to make this happen or am I doomed to always specify that argument?
manage.py sets path to settings for you, that's why it's ignoring DJANGO_SETTINGS_MODULE (it's basically just script that wraps around django-admin.py).
There are 2 easy ways to fix your problem:
set DJANGO_SETTINGS_MODULE and use django-admin.py to run all commands instead of manage.py. This is even better if you use vitualenv.
copy manage.py and name it local.py (that's the name in my case) and rename all settings mentions to dev_settings.
For example:
#!/usr/bin/env python
from django.core.management import execute_manager
import imp
try:
import settings_local
except ImportError:
import sys
sys.stderr.write("Error: Can't find the file 'settings_local.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n" % __file__)
sys.exit(1)
if __name__ == "__main__":
execute_manager(settings_local)
You can run all commands by ./local.py now.
The way this is typically done is you have settings.py with all settings that are common between environments (things like INSTALLED_APPS, etc.). Then, you have something like settings_local.py, that defines settings particular to the environment in context. You then import settings_local.py in settings.py.
# settings.py
from settings_local import *
settings.py gets added to your source code repository, but settings_local.py does not. (However, you would normally add something like settings_local.py.example to the repo.)
When you first move your app over to production, for example, you pull down the code base from your repo. You then copy settings_local.py.example to settings_local.py and make any necessary environment specific changes.
You then have separate settings_local.py files in each environment, and it all just works.
You can make a bash alias by adding these lines to your .bash_profile file:
mymanage()
{
python manage.py $1 --settings=settings_debug
}
alias mng=mymanage
Then when you run this command:
mng runserver
settings_debug.py file will be used for settings.
You can use django-admin.py with that environment variable. Commands are interchangeable, only django-admin.py doesn't override the variable you're trying to use.
If a settings file is common to all installation, you can just import it e.g.
from settings_local import *
but usually settings_local are changed and tweaked per installation and as my installation script directly copy files to target sites (without worrying what is local what is not), which mean settings_local may get overwritten, to avoid that I just keep settings_local in parent folder of the installation target and manually import it in settings.py e.g.
local_settings_file = os.path.join(prevFolder, "settings_local.py")
if os.path.exists(local_settings_file):
execfile(local_settings_file)
I created a sub-directory of my Django project called bin where I want to put all command-line run Python scripts. Some of these scripts need to import my Django project settings.py file that is in a parent directory of bin.
How can I import the settings.py file from a sub-directory of the project?
The code that I use in my command-line script to set into the "Django context" of the project is:
from django.core.management import setup_environ
import settings
setup_environ(settings)
This works fine if the script is in the root directory of my project.
I tried the following two hacks to import the settings.py file and then setup the project:
import os
os.chdir("..")
import sys
sys.path = [str(sys.path[0]) + "/../"] + sys.path
The cruel hack can import settings.py, but then I get the error:
project_module = __import__(project_name, {}, {}, [''])
ValueError: Empty module name
I think your approach may be over-complicating something that Django 1.x provides for you. As long as your project is in your python path, you can set the environment variable DJANGO_SETTINGS_MODULE at the top of your script like so:
import os
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.settings'
In your command line script where you need to read your settings, simply import the settings module from 'django.conf' as you would do in your application code:
from django.conf import settings
And presto, you have your settings and a Django-enabled environment for your script.
I personally prefer to set my DJANGO_SETTINGS_MODULE using '/usr/bin/env' in a bash script called 'proj_env' so I don't have to repeat it
#!/bin/bash
proj_env="DJANGO_SETTINGS_MODULE=myproject.settings"
/usr/bin/env $proj_env ${*}
With this, now I can run any python script with my Django application in context:
proj_env python -m 'myproject.bin.myscript'
If you use virtualenv, this also gives you a good place to source the activate script.
etc. etc.
This is going one level up from your question, but probably the best solution here is to implement your scripts as custom manage.py (django-admin.py) commands. This gives you all of Django's functionality (including settings) for free with no ugly path-hacking, as well as command-line niceties like options parsing. I've never seen a good reason to write Django-related command-line scripts any other way.
Add the parent directory to your path:
import sys
sys.path.append('../')
import settings
Update from comments:
Don't forget the __init__.py file in
the directory that has your
settings.py – S.Lott
Let's say your project directory is /opt/someProject/`
This has files like:
manage.py
Now you have you may have your sub directory anywhere, does not matter.
Eg. subdirectory could be like:
/opt/someproject/dir1/dir2
Now for you to import your project settings inside /opt/someProject/dir1/dir2
You need to set your PYTHONPATH variable
export PYTHONPATH=/opt/someproject/
Now to import modules from bin
from someproject import bin