* Removed type coercion. Options created by argparse are already coerced
to the correct type.
* Removed fallback default values. Options created by argparse already
have a default value.
* Used direct indexing. Options created by argparse are always set. This
eliminates the need to use dict.get().
Debian packages unconditionally byte-compile .py files on installation and
do not silence errors by design. Therefore, we need a way of shipping these
invalid .py files without a .py extension but ensuring that when we
template them, they end up as .py.
We don't special-case .py files so that the all the TemplateCommand
command-line options (eg. extra_files and extensions) still work entirely
as expected and it may even be useful for other formats too.
Also documented missing short command line options to fix#24134. This bumps
the minimum sphinx version required to build the docs to 1.3.4.
Thanks Simon Charette for review.
Django's test suite often tries to load fixture files from apps that have
no fixtures at all. This creates a lot of unnecessary disabling and
enabling of constraints which can be expensive on some database.
To speed this up, loaddata now first checks if any fixture file matches.
If no fixture file is matched, then the command exits before disabling
and enabling of constraints is done.
The main benefit of this change is seen on MSSQL, where tests on
Django 1.8 run hours faster.
In that case, the content of INSTALLED_APPS will be ignored until it's
fixed and the autoreloader kicks in. I confirmed this behavior manually.
As explained on the ticket it's hard to write a test for this case
With this change, it's expected to survive anything except errors
that make it impossible to import the settings. It's too complex
to fallback to a sensible behavior with a broken settings module.
Harcoding things about runserver in ManagementUtility.execute is
atrocious but it's the only way out of the chicken'n'egg problem:
the current implementation of the autoreloader primarily watches
imported Python modules -- and then a few other things that were
bolted on top of this design -- but we want it to kick in even if
the project contains import-time errors and django.setup() fails.
At some point we should throw away this code and replace it by an
off-the-shelf autoreloader that watches the working directory and
re-runs `django-admin runserver` whenever something changes.