Code

Opened 7 years ago

Closed 7 years ago

#4436 closed (wontfix)

./manage.py overwrites DJANGO_SETTINGS_MODULE EnvVar

Reported by: Uz Owned by: nobody
Component: Core (Management commands) Version: 0.96
Severity: Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

django.core.management.setup_environ overwrites this EnvVar with <project_name>.settings even if already set with something meaningful.

Attachments (1)

django_manage.patch (2.7 KB) - added by Evgeniy Tarassov <etarassov@…> 7 years ago.
Patch that let manage.py script to first pick up DJANGO_SETTINGS_MODULE environment variable before falling back to 'settings' module.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 7 years ago by SmileyChris

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

comment:2 follow-up: Changed 7 years ago by SmileyChris

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Triage Stage changed from Unreviewed to Design decision needed

Actually, perhaps you are right and manage.py should leave DJANGO_SETTINGS_MODULE alone if it's already set.

It would be a change in functionality, but I'll leave as a design decision.

comment:3 Changed 7 years ago by akaihola

The current documentation advises to use the DJANGO_SETTINGS_MODULE environment variable and mentions --settings as an alternative.

Also, it's not clear how to specify the settings file for separate Python scripts which use Django and the database. Previously I was able to do this using the DJANGO_SETTINGS_MODULE environment variable, but that's broken now.

All this on SVN. Was this really broken already in 0.96?

comment:4 in reply to: ↑ 2 Changed 7 years ago by Evgeniy Tarassov <etarassov@…>

Replying to SmileyChris:

It would be a change in functionality, but I'll leave as a design decision.

The documentation states that:

manage.py is a thin wrapper around django-admin.py that takes care of two things for you before delegating to django-admin.py:

  1. It puts your project’s package on sys.path.
  1. It sets the DJANGO_SETTINGS_MODULE environment variable so that it points to your project’s settings.py file.

While (1) is undoubtedly useful, the (2) IMHO is at least confusing, because while django-admin is smart enough to pick up the user-defined env-var 'DJANGO_SETTINGS_MODULE', 'manage.py' simply disables the feature.

a) the env-var 'DJANGO_SETTINGS_MODULE' let us avoid typing 'django-admin --settings=...' => saves time => good feature
b) manage.py wrapper let us avoid adding project dir to python sys path => saves time => good feature
What is not good is that ATM these two features simply do not work together.

Please count my vote for restoring the old functionality of manage.py (i.e.make manage.py account for 'DJANGO_SETTINGS_MODULE' and not simply override it with settings).

I'll attach a tiny patch that does what this ticket requests - it's merely a copy-paste from django.conf.

Changed 7 years ago by Evgeniy Tarassov <etarassov@…>

Patch that let manage.py script to first pick up DJANGO_SETTINGS_MODULE environment variable before falling back to 'settings' module.

comment:5 Changed 7 years ago by ubernostrum

  • Resolution set to wontfix
  • Status changed from reopened to closed

Marking wontfix because:

1) It's often useful to have manage.py override so you can work with a different project for a little while, and
2) The --settings option lets you avoid this.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.