#24150 closed Uncategorized (worksforme)
Settings changed at runtime not reflected in management commands
| Reported by: | Aryeh Hillman | Owned by: | nobody |
|---|---|---|---|
| Component: | Core (Management commands) | Version: | 1.7 |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Here is the help text for the collectstatic command:
$ ./manage.py collectstatic --help
Usage: ./manage.py collectstatic [options]
Collect static files in a single location.
Options:
-v VERBOSITY, --verbosity=VERBOSITY
Verbosity level; 0=minimal output, 1=normal output,
2=verbose output, 3=very verbose output
--settings=SETTINGS The Python path to a settings module, e.g.
"myproject.settings.main". If this isn't provided, the
DJANGO_SETTINGS_MODULE environment variable will be
used.
--pythonpath=PYTHONPATH
A directory to add to the Python path, e.g.
"/home/djangoprojects/myproject".
--traceback Raise on exception
--no-color Don't colorize the command output.
--noinput Do NOT prompt the user for input of any kind.
--no-post-process Do NOT post process collected files.
-i PATTERN, --ignore=PATTERN
Ignore files or directories matching this glob-style
pattern. Use multiple times to ignore more.
-n, --dry-run Do everything except modify the filesystem.
-c, --clear Clear the existing files using the storage before
trying to copy or link the original file.
-l, --link Create a symbolic link to each file instead of
copying.
--no-default-ignore Don't ignore the common private glob-style patterns
'CVS', '.*' and '*~'.
--version show program's version number and exit
-h, --help show this help message and exit
Clearly mentioned is a --settings flag, which takes a path to a django settings file. Supposing, however, that we want to run collectstatic from a script and want to dynamically modify our settings file. For example, something like
from django.conf import settings from django.core.management import ManagementUtility settings.USE_S3 = False m = ManagementUtility(['', 'collectstatic']) m.execute()
The command instead uses the settings specified at the shell variable DJANGO_SETTINGS_MODULE instead of the dynamic settings. Kind of pesky to have to create a separate settings file to get control of this sort of thing.
Could also be part of a larger problem -- that collectstatic cannot (easily) be used without the ManagementUtility command. Perhaps the core functionality of collectstatic should be factored out of its management command. For example:
from django.conf import settings
from django.core.management import ManagementUtility
m = ManagementUtility(['', 'collectstatic'])
collectstatic = m.fetch_command('collectstatic')
returns an error:
In [70]: collectstatic.collect()
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
<ipython-input-70-d17fba11a87b> in <module>()
----> 1 collectstatic.collect()
/.../python2.7/site-packages/django/contrib/staticfiles/management/commands/collectstatic.pyc in collect(self)
83 Split off from handle_noargs() to facilitate testing.
84 """
---> 85 if self.symlink and not self.local:
86 raise CommandError("Can't symlink to a remote destination.")
87
AttributeError: 'Command' object has no attribute 'symlink'
Change History (8)
comment:1 by , 11 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 11 years ago
| Description: | modified (diff) |
|---|
comment:3 by , 11 years ago
| Description: | modified (diff) |
|---|
comment:4 by , 11 years ago
| Summary: | collectstatic -- using django.conf.settings → collectstatic -- Dynamic Usage |
|---|
comment:5 by , 11 years ago
comment:6 by , 11 years ago
I was not familiar with that API.
django.core.management.call_command('collectstatic') also uses DJANGO_SETTINGS_MODULE instead of the current django.conf.settings.
comment:7 by , 11 years ago
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
I couldn't reproduce the problem you described with this test script:
import django
from django.conf import settings
from django.core import management
django.setup()
settings.FOO = 'baz'
management.call_command('test')
The test management command simply printed the value of settings.FOO. It always output 'baz' regardless of the value of DJANGO_SETTINGS_MODULE. Please reopen with a minimal test example if I've misinterpreted.
comment:8 by , 11 years ago
| Component: | Uncategorized → Core (Management commands) |
|---|---|
| Summary: | collectstatic -- Dynamic Usage → Settings changed at runtime not reflected in management commands |
call_command() is the public API for calling management commands from your own code. Is there a reason you aren't using that?