A monkey-patcher to ease the transition of project to latest Django versions.
Project description
Compatibility Matters
DCP is a companion application which adds backward/forward compatibility patches to Django, so that your app ecosystem doesn’t get broken by trivial changes made to the core of the framework. You can thus mix bleeding-edge applications with others that are still stuck at much older Django versions.
To know more about the whole concept of Compat Patchers, see the documentation of the underlying Compat Patcher Core.
Note that DCP is aimed at project maintainers. If you are developing a reusable Django application, you can’t expect all your users to integrate DCP as well. In this case, to support a wide range of Django versions, you should rather use a toolkit like Django-compat. You may think of DCP as a “runtime 2to3 and 3to2 for the Django core framework’, whereas Django-Compat is rather a “six module for Django”. If you only seek to upgrade your own codebase to newer Django versions, look at Django Codemod too (which is like a “static 2to3 for Django-dependent code repositories”).
Feel free to ask for (or contribute) new fixers, for backwards or forwards compatibility, depending on the compatibility troubles you encounter on your own projects. See docs/django_deprecation_timeline_notes.rst for a list of breaking changes in Django history, and their current status in DCP.
How to setup
Django-compat-patcher is currently tested on python2.7/3.4/3.5/3.6/3.7/3.8, with Django versions 1.8/1.9/1.10/1.11/2.0/2.1/2.2/3.0, where these combinations make sense (e.g. Django2+ dropped support for Python2).
First add django-compat-patcher
to your project requirements, or install it directly with pip install django-compat-patcher.
Activation method 1 - with code
You can activate patching with:
import django_compat_patcher django_compat_patcher.patch()
This code should be placed before any use of Django (eg. in your manage.py
or your wsgi.py
script), but after the DJANGO_SETTINGS_MODULE
environment variable has been set.
In particular, some fixers only work if they are applied before the loading of INSTALLED_APPS (so before django.setup() gets called).
The Django settings of your project are not altered by compatibility shims, so they should be kept up-to-date with your installed Django version (eg. now use TEMPLATES, MIDDLEWARE, and not deprecated equivalents). In particular, always put real package names in INSTALLED_APPS, not their potential “import aliases”.
Despite DCP patching, you might encounter errors raised by the Django check framework, like the following. Use the SILENCED_SYSTEM_CHECKS setting to bypass such blocking checks.
(fields.E900) IPAddressField has been removed except for support in historical migrations. HINT: Use GenericIPAddressField instead. (fields.E160) The options auto_now, auto_now_add, and default are mutually exclusive. Only one of these options may be present.
Activation method 2 - with launcher
You may force the patching of Django at python startup using https://pypi.org/project/main-wrapper/:
pip install main-wrapper export DJANGO_SETTINGS_MODULE=<your-settings-module> # Mandatory export DCP_INCLUDE_FIXER_FAMILIES='["django3.0"]' # Optional DCP setting tweaks python-main-wrapper django_compat_patcher:patch <your-normal-command-line>
This unintrusive method is especially useful to repeatedly launch the unit-tests of a library, with different settings, and thus determine how many fixers it needs to function properly under latest Django version:
python-main-wrapper django_compat_patcher:patch django test python-main-wrapper django_compat_patcher:patch pytest python-main-wrapper django_compat_patcher:patch -m <some-module>
See python-main-wrapper -h for more details on this launcher.
Tweaking DCP settings
By default, DCP emits logs and warnings when patching the code, and applies all “relevant” fixers, i.e all that support your currently installed django version, and are not deemed unsafe.
Unsafe fixers are the few ones which might conflict with modern third-party libraries , e.g. if these add their own workarounds for Django incompatibilites (see DCP_EXCLUDE_FIXER_IDS default below).
This behaviour can be customized via the Django settings documented below.
Note however, that some fixers depend on other fixers, so it’s advised to be consistent and always include contiguous series of fixers around your current version (ex. if you use Django1.11, apply fixers from Django1.8 up to Django1.11, or up to Django2.X if yo want some forward compatibility as well). DCP filters out, by himself, fixers which are useless for your Django version.
You might also provide a settings dictionary directly to patch(), in which case the DCP django settings of your project will be entirely ignored (only DCP library defaults will be used as fallbacks):
django_compat_patcher.patch(settings=dict(DCP_INCLUDE_FIXER_IDS=["my_fixer_id"]))
It is also possible to override only one or more of these settings by using environment variables with the same name (e.g. “DCP_INCLUDE_FIXER_IDS”), in JSON format (so a string must be passed as ‘”*”’ for example, or a boolean as ‘true’; beware of single quotes, forbidden for JSON strings).
Note that exclusion filters have precedence over inclusion ones.
DCP_INCLUDE_FIXER_IDS
List of fixer identifiers to include. If "*"
is used, then all fixers are included.
In rare case of name conflicts when using several registries at once, you may use qualified qualified fixer names like “fixer_family|fixer_id”.
'*'
"*"
DCP_INCLUDE_FIXER_IDS = ['fix_deletion_templatetags_future_url']
DCP_INCLUDE_FIXER_FAMILIES
List of fixer families to include. If "*"
is used, then all families are included.
Note: If you want to include only specific families, remember to replace the value "*" from :code:`DCP_INCLUDE_FIXER_IDS
by, for example, an empty list.
[]
"*"
("djangoX.Y")
where X
and Y
are respectively the major and minor versionsDCP_INCLUDE_FIXER_FAMILIES = ["django1.9"]
DCP_EXCLUDE_FIXER_IDS
List of fixer identifiers to exclude. If "*"
is used, then all fixers are excluded.
In rare case of name conflicts when using several registries at once, you may use qualified qualified fixer names like “fixer_family|fixer_id”.
Note: The “EXCLUDE” filters are applied AFTER the “INCLUDE” ones, and so take precedence.
['fix_behaviour_core_management_parser_optparse']
"*"
DCP_EXCLUDE_FIXER_IDS = ['fix_deletion_templatetags_future_url']
DCP_EXCLUDE_FIXER_FAMILIES
List of fixer families to exclude. If "*"
is used, then all families are excluded.
Note: The “EXCLUDE” filters are applied AFTER the “INCLUDE” ones, and so take precedence.
[]
"*"
("djangoX.Y")
where X
and Y
are respectively the major and minor versionsDCP_EXCLUDE_FIXER_FAMILIES = ["django1.6", "django1.9"]
DCP_PATCH_INJECTED_OBJECTS
By default, the patcher sets an attribute (with value True
) on injected objects (callables, classes, modules, attributes…) when possible,
with this attribute name, to differentiate them from original objects. Set this setting to True to automatically choose the attribute name, or False to disable the feature.
'__dcp_injected__'
DCP_PATCH_INJECTED_OBJECTS = False
DCP_ENABLE_WARNINGS
If True, compatibility shims emit python warnings (warnings.warn(...)
) when they are imported/used,
to help detect deprecated code. These warnings are mostly subclasses of DeprecationWarning
(ex. RemovedInDjango19Warning
).
Once emitted, the handling of warnings depends on your setup (python command line flags, logging config…), see the official doc on warnings for more information.
True
DCP_ENABLE_WARNINGS = False
DCP_LOGGING_LEVEL
The patch() system of DCP can output to STDERR which fixers are getting applied, and provide debug information (ex. for which reason a specific fixer was discarded).
This setting sets the logging level of that information stream, which is typically only viewed at django startup. A value None
disables DCP logging entirely.
Note that DCP does NOT actually use stdlib loggers, because it mostly performs operations before Django logging has been setup (ex. using the LOGGING setting), so log entries would most probably get discarded.
'INFO'
DCP_LOGGING_LEVEL = "DEBUG"
Table of fixers
There are currently 50 available fixers.
Fixer and its ID |
Fixer family |
Min version |
Max version |
---|---|---|---|
Preserve the request.raw_post_data alias for request.body. ( |
django1.6 |
1.6 |
|
Keep ‘django.contrib.comments’ as an import alias for the now external package ‘django_comments’ (django-contrib-comments on pypi) ; the latter must be installed separately. ( |
django1.8 |
1.8 |
|
Preserve the get_formsets method of ModelAdmin ( |
django1.9 |
1.9 |
|
Preserve contrib.sites.models.RequestSite alias. ( |
django1.9 |
1.9 |
|
Preserve contrib.sites.models.get_current_site alias. ( |
django1.9 |
1.9 |
|
Preserve django.core.cache.get_cache() utility, superseded by django.core.cache.caches ( |
django1.9 |
1.9 |
|
Preserve the `request.REQUEST` attribute, merging parameters from GET ( |
django1.9 |
1.9 |
|
Preserve the fallback to AppCommand.handle_app() method in django management commands. ( |
django1.9 |
1.9 |
|
Preserve the IPAddressField form field, now superseded by GenericIPAddressField ( |
django1.9 |
1.9 |
|
Preserve the `ssi` tag in the `future` templatetags library. ( |
django1.9 |
1.9 |
|
Preserve the `url` tag in the `future` templatetags library. ( |
django1.9 |
1.9 |
|
Preserve the MergeDict util datastructure ( |
django1.9 |
1.9 |
|
Preserve the SortedDict util datastructure ( |
django1.9 |
1.9 |
|
Preserve the dictconfig util file ( |
django1.9 |
1.9 |
|
Preserve utils.functional.memoize() utility ( |
django1.9 |
1.9 |
|
Preserve the importlib util file ( |
django1.9 |
1.9 |
|
Preserve the tzinfo util file ( |
django1.9 |
1.9 |
|
Preserve the unittest util file ( |
django1.9 |
1.9 |
|
Support passing views to url() as dotted strings instead of view objects. ( |
django1.10 |
1.10 |
|
Preserve the support for old optparse instead of argparse parser, in management commands. Beware, Bash shell autocompletion might fail if some management commands use Optparse! ( |
django1.10 |
1.10 |
|
Preserve the ability to call urlresolver on dotted string view, instead of explicit view name. ( |
django1.10 |
1.10 |
|
Preserve support for a single ‘=’ sign in {% if %} tag. ( |
django1.10 |
1.10 |
|
Restore support for dotted-string view parameter in RegexURLPattern, instead passing a view object. ( |
django1.10 |
1.10 |
|
Preserve the patterns() builder for django urls. ( |
django1.10 |
1.10 |
|
Preserve the “ssi” default template tag. ( |
django1.10 |
1.10 |
|
Preserve the “future” templatetags library, with its improved `firstof` and `cycle` tags. ( |
django1.10 |
1.10 |
|
Put a forward compatibility import path for django.urls, which replaces django.core.urlresolvers ( |
django1.10 |
1.10 |
|
Preserve compatibility with the old signature of Widget.build_attrs(): extra_attrs=None, **kwargs. ( |
django1.11 |
1.11 |
|
Keep accepting a 3-tuple (urlconf_module, app_name, namespace) as first argument of include(), instead of providing namespace argument directly to include() ( |
django2.0 |
2.0 |
|
Make user.is_anonymous and user.is_authenticated behave both as properties and methods, by preserving their callability like in earlier Django version. ( |
django2.0 |
2.0 |
|
Let “on_delete” parameter of ForeignKey and OneToOneField be optional, defaulting to CASCADE. ( |
django2.0 |
2.0 |
|
Preserve django.core.urlresolvers module, now replaced by django.urls. ( |
django2.0 |
2.0 |
|
Preserve the Context.has_key() utility, replaced by “in” operator use. ( |
django2.0 |
2.0 |
|
Preserve the assignment_tag() helper, superseded by simple_tag(). ( |
django2.0 |
2.0 |
|
Preserve RegexURLPattern and RegexURLResolver in django.urls, which disappeared due to DEP 0201. ( |
django2.0 |
2.0 |
|
Preserve the allow_lazy() utility, superseded by keep_lazy(). ( |
django2.0 |
2.0 |
|
Preserve the javascript_catalog() and json_catalog() i18n views, superseded by class-based views. ( |
django2.0 |
2.0 |
|
Restore the behaviour where the “renderer” parameter of Widget.render() may not be supported by subclasses. ( |
django2.1 |
2.1 |
|
Preserve django.utils.translation.string_concat(), superseded by django.utils.text.format_lazy(). ( |
django2.1 |
2.1 |
|
Preserve django.shortcuts.render_to_response(), superseded by render(). ( |
django3.0 |
3.0 |
|
Preserve django.test.utils.patch_logger() context manager. ( |
django3.0 |
3.0 |
|
Preserve django.test.utils.str_prefix class. ( |
django3.0 |
3.0 |
|
Preserve django.utils.decorators.ContextDecorator, alias of contextlib.ContextDecorator. ( |
django3.0 |
3.0 |
|
Preserve django.utils.decorators.available_attrs, which just returns functools.WRAPPER_ASSIGNMENTS. ( |
django3.0 |
3.0 |
|
Preserve django.utils.encoding.python_2_unicode_compatible() class decorator. ( |
django3.0 |
3.0 |
|
Preserve django.utils.functional.curry()function. ( |
django3.0 |
3.0 |
|
Preserve django.utils.lru_cache.lru_cache(), alias of functools.lru_cache(), and its containing module. ( |
django3.0 |
3.0 |
|
Preserve django.utils.safestring.SafeBytes class. ( |
django3.0 |
3.0 |
|
Preserve the vendored copy of “six” compatibility utility, in django.utils ( |
django3.0 |
3.0 |
|
Preserve python2 path normalization functions. ( |
django3.0 |
3.0 |
Project details
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
File details
Details for the file django-compat-patcher-0.8.tar.gz
.
File metadata
- Download URL: django-compat-patcher-0.8.tar.gz
- Upload date:
- Size: 80.3 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/1.12.1 pkginfo/1.5.0.1 requests/2.18.4 setuptools/40.6.3 requests-toolbelt/0.8.0 tqdm/4.29.1 CPython/2.7.12
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | 5a3e00fa45bcb486ac674f88d024b8bdb3a10622e4904bf3acba3241f0a3e266 |
|
MD5 | f6ceebf9f25f309796f2d5cd0c3908ce |
|
BLAKE2b-256 | 81fc61f0c756d33fc22e27c77b9c2fb71f2e01c331e4d0ca6ce2609af2cfb3b7 |