Shallow copying of `django.utils.functional.LazyObject` or its subclasses has
been broken in a couple of different ways in the past, most recently due to
35355a4.
Prior to 55f12f8709, the template origin was available on each node via
`self.token.source[0]`. This behavior was removed when debug handling was
simplified, but 3rd-party debugging tools still depend on its presence.
This updates the Parser to set origin on individual nodes. This enables the
source template to be determined even when template extending or including is
used.
This was causing an issue when calling the `migrate` command in a test case with
the `available_apps` attribute pointing to an application with migrations
disabled using the `MIGRATION_MODULES` setting.
Thanks to Tim Graham for the review.
Refs #24919
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.
If SQLITE_MAX_VARIABLE_NUMBER (default = 999) is changed at compile time
to be greater than SQLITE_MAX_COLUMN (default = 2000), which Debian does
by setting the former to 250000, Django raised an exception on queries
containing more than 2000 parameters when DEBUG = True.
