Automatically upgrade your Django projects.

Overview

django-upgrade

https://img.shields.io/github/workflow/status/adamchainz/django-upgrade/CI/main?style=for-the-badge https://img.shields.io/badge/Coverage-100%25-success?style=for-the-badge https://img.shields.io/pypi/v/django-upgrade.svg?style=for-the-badge https://img.shields.io/badge/code%20style-black-000000.svg?style=for-the-badge pre-commit

Automatically upgrade your Django projects.

Installation

Use pip:

python -m pip install django-upgrade

Python 3.8 to 3.10 supported.

Or with pre-commit in the repos section of your .pre-commit-config.yaml file (docs):

-   repo: https://github.com/adamchainz/django-upgrade
    rev: ''  # replace with latest tag on GitHub
    hooks:
    -   id: django-upgrade
        args: [--target-version, "3.2"]   # Replace with Django version

Are your tests slow? Check out my book Speed Up Your Django Tests which covers loads of best practices so you can write faster, more accurate tests.


Usage

django-upgrade is a commandline tool that rewrites files in place. Pass your Django version as <major>.<minor> to the --target-version flag. The built-in fixers will rewrite your code to avoid some DeprecationWarnings and use some new features on your Django version. For example:

django-upgrade --target-version 3.2 example/core/models.py example/settings.py

The --target-version flag defaults to 2.2, the oldest supported version when this project was created. For more on usage run django-upgrade --help.

django-upgrade focuses on upgrading your code for the “99% case” and not on making it look nice. Run django-upgrade before your reformatters, such as isort or Black.

The full list of fixers is documented below.

History

django-codemod is a pre-existing, more complete Django auto-upgrade tool, written by Bruno Alla. Unfortunately its underlying library LibCST is particularly slow, making it annoying to run django-codemod on every commit and in CI. Additionally LibCST only advertises support up to Python 3.8 (at time of writing).

django-upgrade is an experiment in reimplementing such a tool using the same techniques as the fantastic pyupgrade. The tool leans on the standard library’s ast and tokenize modules, the latter via the tokenize-rt wrapper. This means it will always be fast and support the latest versions of Python.

For a quick benchmark: running django-codemod against a medium Django repository with 153k lines of Python takes 133 seconds. pyupgrade and django-upgrade both take less than 0.5 seconds.

Fixers

Django 1.9

Release Notes

on_delete argument

Add on_delete=models.CASCADE to ForeignKey and OneToOneField:

-models.ForeignKey("auth.User")
+models.ForeignKey("auth.User", on_delete=models.CASCADE)

-models.OneToOneField("auth.User")
+models.OneToOneField("auth.User", on_delete=models.CASCADE)

Compatibility imports

Rewrites some compatibility imports:

  • django.forms.utils.pretty_name in django.forms.forms
  • django.forms.boundfield.BoundField in django.forms.forms

Whilst mentioned in the Django 3.1 release notes, these have been possible since Django 1.9.

-from django.forms.forms import pretty_name
+from django.forms.utils import pretty_name

Django 1.11

Release Notes

Compatibility imports

Rewrites some compatibility imports:

  • django.core.exceptions.EmptyResultSet in django.db.models.query, django.db.models.sql, and django.db.models.sql.datastructures
  • django.core.exceptions.FieldDoesNotExist in django.db.models.fields

Whilst mentioned in the Django 3.1 release notes, these have been possible since Django 1.11.

-from django.db.models.query import EmptyResultSet
+from django.core.exceptions import EmptyResultSet

-from django.db.models.fields import FieldDoesNotExist
+from django.core.exceptions import FieldDoesNotExist

Django 2.0

Release Notes

URL’s

Rewrites imports of include() and url() from django.conf.urls to django.urls. url() calls using compatible regexes are rewritten to the new path() syntax, otherwise they are converted to call re_path().

-from django.conf.urls import include, url
+from django.urls import include, path, re_path

 urlpatterns = [
-    url(r'^$', views.index, name='index'),
+    path('', views.index, name='index'),
-    url(r'^about/$', views.about, name='about'),
+    path('about/', views.about, name='about'),
-    url(r'^post/(?P<slug>[w-]+)/$', views.post, name='post'),
+    re_path(r'^post/(?P<slug>[w-]+)/$', views.post, name='post'),
-    url(r'^weblog/', include('blog.urls')),
+    path('weblog/', include('blog.urls')),
 ]

lru_cache

Rewrites imports of lru_cache from django.utils.functional to use functools.

-from django.utils.functional import lru_cache
+from functools import lru_cache

Django 2.2

Release Notes

HttpRequest.headers

Rewrites use of request.META to read HTTP headers to instead use request.headers.

-request.META['HTTP_ACCEPT_ENCODING']
+request.headers['Accept-Encoding']

-self.request.META.get('HTTP_SERVER', '')
+self.request.headers.get('Server', '')

QuerySetPaginator

Rewrites deprecated alias django.core.paginator.QuerySetPaginator to Paginator.

-from django.core.paginator import QuerySetPaginator
+from django.core.paginator import Paginator

-QuerySetPaginator(...)
+Paginator(...)

FixedOffset

Rewrites deprecated class FixedOffset(x, y)) to timezone(timedelta(minutes=x), y)

Known limitation: this fixer will leave code broken with an ImportError if FixedOffset is called with only *args or **kwargs.

-from django.utils.timezone import FixedOffset
-FixedOffset(120, "Super time")
+from datetime import timedelta, timezone
+timezone(timedelta(minutes=120), "Super time")

FloatRangeField

Rewrites model and form fields using FloatRangeField to DecimalRangeField, from the relevant django.contrib.postgres modules.

 from django.db.models import Model
-from django.contrib.postgres.fields import FloatRangeField
+from django.contrib.postgres.fields import DecimalRangeField

 class MyModel(Model):
-    my_field = FloatRangeField("My range of numbers")
+    my_field = DecimalRangeField("My range of numbers")

TestCase class database declarations

Rewrites the allow_database_queries and multi_db attributes of Django’s TestCase classes to the new databases attribute. This only applies in test files, which are heuristically detected as files with either “test” or “tests” somewhere in their path.

Note that this will only rewrite to databases = [] or databases = "__all__". With multiple databases you can save some test time by limiting test cases to the databases they require (which is why Django made the change).

 from django.test import SimpleTestCase

 class MyTests(SimpleTestCase):
-    allow_database_queries = True
+    databases = "__all__"

     def test_something(self):
         self.assertEqual(2 * 2, 4)

Django 3.0

Release Notes

django.utils.encoding aliases

Rewrites smart_text() to smart_str(), and force_text() to force_str().

-from django.utils.encoding import force_text, smart_text
+from django.utils.encoding import force_str, smart_str


-force_text("yada")
-smart_text("yada")
+force_str("yada")
+smart_str("yada")

django.utils.http deprecations

Rewrites the urlquote(), urlquote_plus(), urlunquote(), and urlunquote_plus() functions to the urllib.parse versions. Also rewrites the internal function is_safe_url() to url_has_allowed_host_and_scheme().

-from django.utils.http import urlquote
+from urllib.parse import quote

-escaped_query_string = urlquote(query_string)
+escaped_query_string = quote(query_string)

django.utils.text deprecation

Rewrites unescape_entities() with the standard library html.escape().

-from django.utils.text import unescape_entities
+import html

-unescape_entities("some input string")
+html.escape("some input string")

django.utils.translation deprecations

Rewrites the ugettext(), ugettext_lazy(), ugettext_noop(), ungettext(), and ungettext_lazy() functions to their non-u-prefixed versions.

-from django.utils.translation import ugettext as _, ungettext
+from django.utils.translation import gettext as _, ngettext

-ungettext("octopus", "octopodes", n)
+ngettext("octopus", "octopodes", n)

Django 3.1

Release Notes

JSONField

Rewrites imports of JSONField and related transform classes from those in django.contrib.postgres to the new all-database versions.

-from django.contrib.postgres.fields import JSONField
+from django.db.models import JSONField

PASSWORD_RESET_TIMEOUT_DAYS

Rewrites the setting PASSWORD_RESET_TIMEOUT_DAYS to PASSWORD_RESET_TIMEOUT, adding the multiplication by the number of seconds in a day.

Settings files are heuristically detected as modules with the whole word “settings” somewhere in their path. For example myproject/settings.py or myproject/settings/production.py.

-PASSWORD_RESET_TIMEOUT_DAYS = 4
+PASSWORD_RESET_TIMEOUT = 60 * 60 * 24 * 4

Signal

Removes the deprecated documentation-only providing_args argument.

 from django.dispatch import Signal
-my_cool_signal = Signal(providing_args=["documented", "arg"])
+my_cool_signal = Signal()

get_random_string

Injects the now-required length argument, with its previous default 12.

 from django.utils.crypto import get_random_string
-key = get_random_string(allowed_chars="01234567899abcdef")
+key = get_random_string(length=12, allowed_chars="01234567899abcdef")

NullBooleanField

Transforms the NullBooleanField() model field to BooleanField(null=True).

-from django.db.models import Model, NullBooleanField
+from django.db.models import Model, BooleanField

 class Book(Model):
-    valuable = NullBooleanField("Valuable")
+    valuable = BooleanField("Valuable", null=True)

Django 3.2

Release Notes

EmailValidator

Rewrites keyword arguments to their new names: whitelist to allowlist, and domain_whitelist to domain_allowlist.

 from django.core.validators import EmailValidator

-EmailValidator(whitelist=["example.com"])
+EmailValidator(allowlist=["example.com"])
-EmailValidator(domain_whitelist=["example.org"])
+EmailValidator(domain_allowlist=["example.org"])

Django 4.0

Release Notes

There are no fixers for Django 4.0 at current. Most of its deprecations don’t seem automatically fixable.

Comments
  • Rewrite `admin.site.register()` to `@admin.register()`

    Rewrite `admin.site.register()` to `@admin.register()`

    Description

    Description

    We could rewrite admin.site.register() to the more elegant @admin.register() syntax :

    [email protected](MyModel)
    class MyCustomAdmin:
        pass
    
    -admin.site.register(MyModel, MyCustomAdmin)
    

    This syntax was actually added a while ago (Django1.7). I usually find it a bit easier to use since the Model and associated Custom Admin definition stay really close.

    Potential Issue

    There is a known issue when using a python 2 style super call in the __init__ method. The fixer should not rewrite in this case.

    You can’t use this decorator if you have to reference your model admin class in its __init__() method, e.g. super(PersonAdmin, self).__init__(*args, **kwargs). You can use super().__init__(*args, **kwargs).

    Let me know if this is something you'll be interested in, I'll be happy to submit a PR. Cheers

    opened by UnknownPlatypus 9
  • Undesired rewriting of import statements (pre-commit loop)

    Undesired rewriting of import statements (pre-commit loop)

    Python Version

    3.8

    Django Version

    2.2

    Package Version

    main

    Description

    I need some help triaging this behavior, as I'm not familiar with the patterns that django-upgrade uses to detect and alter import statements.

    While running django-upgrade on a project, I have the following import statement generated:

    from django.urls import include, path, re_path
    

    However, if my project is using reorder_python_imports, it will split up this line into 3 import statements:

    from django.urls import include
    from django.urls import path
    from django.urls import re_path
    

    Now, if I run the django-upgrade hook again, the former line reappears like this:

    from django.urls import include
    from django.urls import path
    from django.urls import include, path, re_path
    

    You can add the latest version of reorder_python_imports with this configuration:

    -   repo: https://github.com/asottile/reorder_python_imports
        rev: v3.8.3
        hooks:
        -   id: reorder-python-imports
            language_version: python3
    
    

    Are you able to immediately grasp the issue @adamchainz or does it need to be isolated into a test project / test case?

    The correct behavior?

    I think that what I would expect from django-upgrade is that it generates whatever import statements that it needs, but that subsequent linting from black, flake8 or reorder_python_imports is left in place and doesn't result in any new changes.

    opened by benjaoming 6
  • Document ``path`` converter regexes and limitation

    Document ``path`` converter regexes and limitation

    I noticed while testing on a personal project that the url slug rewriter was matching the [-a-zA-Z0-9_]+ but not the equivalent [\w-] or [-\w].

    I thought maybe we could support that too ?

    opened by UnknownPlatypus 6
  • Fix urls fixer wrong import rewrite

    Fix urls fixer wrong import rewrite

    My attempt to fix #250.

    I noticed that the underlying issue is that some noop tests are actually doing rewrites.

    For exemple, the following is actually triggering an erase/rewrite of the import node but since it rewrites the same thing we don't notice it:

    def test_fake_noop():
        check_noop(
            """\
            from django.urls import re_path
    
            re_path('whatever')
            """,
            settings,
        )
    

    I added a state_added_names variable to keep track of names that will need to be imported. Then I can only add an import with these names (minus the ones initially imported).

    PS: Last commit replace the state_used_names variable with state_re_path_used because it was only needed to determine if the re_path import can be removed.

    I'm unsure if it's the best way to deal with this so I'm happy to take any feed back. At least maybe this will give you some food for thoughts on your attempt.

    Cheers

    opened by UnknownPlatypus 5
  • Extensions to `@admin.register` fixer

    Extensions to `@admin.register` fixer

    Description

    Following #182 / #189 , there are a few more cases that could be covered with further work.

    1. Support kwarg form ✅ #192
    [email protected](MyModel)
     class MyModelAdmin(...):
        ...
    
    -admin.site.register(MyModel, admin_class=MyModelAdmin)
    
    1. Support multiple models ✅ #200
    [email protected](Model1, Model2)
     class MyModelAdmin(...):
        ...
    
    -admin.site.register(Model1, MyModelAdmin)
    -admin.site.register(Model2, MyModelAdmin)
    
    [email protected](Model1, Model2)
     class MyModelAdmin(...):
        ...
    
    -admin.site.register((Model1, Model2), MyModelAdmin)
    
    1. Support when there are other class decorators, insert at top ✅ #193
    [email protected](MyModel)
     @something
     class MyModelAdmin(...):
        ...
    
    -admin.site.register(MyModel, MyModelAdmin)
    
    1. Support custom admin sites ✅ #228
    from myapp.admin import custom_site
    
    [email protected](MyModel, site=custom_site)
     class MyModelAdmin(...):
        ...
    
    -custom_site.register(MyModel, MyModelAdmin)
    
    • detect custom site objects heuristically, to avoid affecting other code that uses a 'register' pattern, perhaps when the object's name ends in 'site', and the registered class name ends in 'Admin' (and maybe the file looks like an admin file, called "admin.py" or in an "admin" directory?)
    1. Also work for from django.contrib.gis import admin - ✅ #204 This imports the register decorator for convenience when authoring GIS apps.
    opened by adamchainz 5
  • HttpRequest.META is not deprecated

    HttpRequest.META is not deprecated

    Python Version

    3.8.10

    Django Version

    3.2

    Package Version

    1.0.0

    Description

    According to the documentation of HttpRequest.META, HttpRequest.META is not deprecated in any version of django, so the rule in django-upgrade which converts these calls to request.headers and removes the HTTP prefix looks like it is too strict.

    opened by quentinelwin 5
  • NullBooleanField upgraded to BooleanField in migrations file

    NullBooleanField upgraded to BooleanField in migrations file

    Python Version

    3.10

    Django Version

    3.2.5 --> 4.1

    Package Version

    1.11.0

    Description

    While using django upgrade on the entire django project using the following in the main django project folder (powershell): git ls-files -- '*.py' | %{django-upgrade --target-version 4.1 $_}

    Also the migration files where targeted (one of the files before conversion, located at projects > migrations):

    # Generated by Django 2.1.7 on 2020-04-24 10:49
    
    from django.db import migrations, models
    
    
    class Migration(migrations.Migration):
    
        dependencies = [
            #('projects', '0237_auto_20200420_0955'),
            ('projects', '0002_auto_20200512_1030'),
        ]
    
        operations = [
            migrations.AddField(
                model_name='historicalsequenceequipment',
                name='cond_data',
                field=models.NullBooleanField(default=False),
            ),
            migrations.AddField(
                model_name='sequenceequipment',
                name='cond_data',
                field=models.NullBooleanField(default=False),
            ),
        ]
    
    

    As the docs says that these were not included in the NullBooleanField change & the code checks for state.looks_like_migrations_file in this fixer, this seemed like a bug to me ("migrations" is in the file path as it is the folder name)

    Thanks for the package, I'm loving it! William

    opened by CLWilliam 4
  • Preserve double quotes when rewriting string tokens

    Preserve double quotes when rewriting string tokens

    I was attempting to use django-upgrade on a project which prefers double quotes over single quotes, meaning when something was rewritten like:

    -request.META["HTTP_SERVER"]
    +request.headers['Server']
    

    it's linter would complain that it's expecting double quotes.

    I'm not sure this solution is fully comprehensive but wanted to get feedback before spending any more time on it, but hopefully it's not too controversial to keep the existing quote style during rewrites.

    opened by kevinmarsh 4
  • Support custom admin classes in @admin.register fixer

    Support custom admin classes in @admin.register fixer

    For #190

    Hey, so I started working on the custom admin support and I had a few interrogations to finish it.

    1. Is a stacked syntax ok when the same admin model is used to register a model against different sites ?
    class MyAdminSite(admin.AdminSite):
        site_header = "My very custom administration"
    
    custom_site = MyAdminSite(name="myadmin")
    
    [email protected](Comment)
    [email protected](Comment, site=custom_site)
    class CommentAdmin(admin.ModelAdmin):
        pass
    
    
    -admin.site.register(Comment, CommentAdmin)
    -custom_site.register(Comment, CommentAdmin)
    
    1. What should I do if from django.contrib import admin is missing (I suppose it's quitte common if you work with custom sites). I'm not sure where to add the import

    2. Should we extend the looks_like_admin_file check heuristic to the regular fixers too ?

    opened by UnknownPlatypus 4
  • Delete `USE_L10N` setting if Django version >= 4.0

    Delete `USE_L10N` setting if Django version >= 4.0

    Description

    The USE_L10N setting is deprecated in Django 4.0: https://docs.djangoproject.com/en/4.0/ref/settings/#std-setting-USE_L10N

    Figure this would be a good candidate for this project. Happy to work on it if you agree.

    opened by johnnymetz 4
  • Migrate django.utils.timezone.utc to datetime.timezone.utc

    Migrate django.utils.timezone.utc to datetime.timezone.utc

    Description

    Django 4.1 deprecates the django.utils.timezone.utc alias to datetime.timezone.utc. Folks should use datetime.timezone.utc directly.

    https://github.com/django/django/commit/59ab3fd0e9e606d7f0f7ca26609c06ee679ece97

    This seems like a good candidate for django-upgrade, as @adamchainz convincingly argued on a recent Django Chat 🎙😜

    opened by carltongibson 4
  • Add HTTP Headers fixer for Client and RequestFactory.

    Add HTTP Headers fixer for Client and RequestFactory.

    Fixes https://github.com/adamchainz/django-upgrade/issues/271

    At the moment, it's just a first draft, to get the idea. Some cases are not handled yet, and we will have to decide how far to push the handled cases :)

    Used for https://github.com/django/django/pull/16401

    opened by David-Wobrock 0
  • Group compatibility imports

    Group compatibility imports

    Hi !

    Here is the grouping part discussed in #293. I measured a ~3% performance improvement on the same test repository I generally use (5k python files, 483kloc).

    I think it's really cheap now to add the older compatibility imports given the new structure. Let me know how you feel about it.

    opened by UnknownPlatypus 0
  • Support more compatibility import rewrites

    Support more compatibility import rewrites

    Description

    I noticed while browsing django codebase for warnings.warn that some (rather old) compatibility imports were not supported by django-upgrade.

    Do you think it could be a valuable addition ?

    I was thinking of using a similar pattern to anthony's compatibility import plugin by keeping a mapping of django-version -> import (similar to the current REWRITES mappings) while still relying on the django-upgrade update_import_modules for the actual fixing.

    This could maybe lead to a small performance improvement too by grouping the existing fixer that are mostly checking the same things. As always, I'm happy to send a PR!


    Here are the compatibility imports that I think are not currently covered.

    Imports

    --target-version 2.0

    • django.utils.decorators.ContextDecorator -> contextlib.ContextDecorator: Undocumented - source

    --target-version 1.11

    • django.test.runner.setup_databases() -> django.test.utils.setup_databases() : release note - source - RemovedInDjango21

    --target-version 1.10

    • django.contrib.staticfiles.templatetags.staticfiles.static() -> django.templatetags.static.static(): release note - source 1.10 - RemovedInDjango30
    • django.core.urlresolvers.* -> django.urls.*: release note - source - RemovedInDjango20

    --target-version 1.9

    • django.db.backends.postgresql_psycopg2.* -> django.db.backends.postgresql.*: release note - source - RemovedInDjango30.
    • django.forms.extras.SelectDateWidget -> django.forms.widgets.SelectDateWidget: release note - source - RemovedInDjango20

    --target-version 1.8

    • django.core.context_processors.* -> django.template.context_processors.*: release note - source - RemovedInDjango110
    • django.db.models.sql.aggregates -> django.db.models.aggregates: release note - source - RemovedInDjango110

    --target-version 1.6

    • django.template.base.Context -> django.template.context.Context: Same for BaseContext, ContextPopException and RequestContext: release note - source - RemovedInDjango31

    --target-version 1.1

    • django.contrib.admin.ACTION_CHECKBOX_NAME -> django.contrib.admin.helpers.ACTION_CHECKBOX_NAME : release note - source - RemovedInDjango31
    opened by UnknownPlatypus 2
  • Python compat path removal based on Django’s `PY*` constants

    Python compat path removal based on Django’s `PY*` constants

    Description

    Django has private constants for Python version:

    https://github.com/django/django/blob/84206607d6bfd61e7f7a88b51163ffd4153e3b5a/django/utils/version.py#L9-L18

    We could copy pyupgrade’s old version removal feature for these constants.

    Taking an extra argument with the target Python version might be a bit of feature creep. Perhaps we could instead take the minimum supporte Python version from the target Django version (each Django version’s release notes lists the supported Python version, we’d need that data in django-upgrade).

    opened by adamchainz 0
  • Option to select specific fixer to run

    Option to select specific fixer to run

    Description

    It would be nice to have the option to specify one or more fixer to apply. One usecase is to be able to categorise the changes in several different commits, and another usecase is the codebase might not be ready to apply some of the fixes but others.

    opened by cgl 3
Owner
Adam Johnson
🦄 @django technical board member 🇬🇧 @djangolondon co-organizer ✍ AWS/Django/Python Author and Consultant
Adam Johnson
Cookiecutter Django is a framework for jumpstarting production-ready Django projects quickly.

Cookiecutter Django Powered by Cookiecutter, Cookiecutter Django is a framework for jumpstarting production-ready Django projects quickly. Documentati

Daniel Feldroy 10k Dec 31, 2022
A handy tool for generating Django-based backend projects without coding. On the other hand, it is a code generator of the Django framework.

Django Sage Painless The django-sage-painless is a valuable package based on Django Web Framework & Django Rest Framework for high-level and rapid web

sageteam 51 Sep 15, 2022
Django URL Shortener is a Django app to to include URL Shortening feature in your Django Project

Django URL Shortener Django URL Shortener is a Django app to to include URL Shortening feature in your Django Project Install this package to your Dja

Rishav Sinha 4 Nov 18, 2021
:couple: Multi-user accounts for Django projects

django-organizations Summary Groups and multi-user account management Author Ben Lopatin (http://benlopatin.com / https://wellfire.co) Status Separate

Ben Lopatin 1.1k Jan 1, 2023
Analytics services for Django projects

django-analytical The django-analytical application integrates analytics services into a Django project. Using an analytics service with a Django proj

Jazzband 1.1k Dec 31, 2022
Ugly single sign-on for django projects only

django-usso Ugly single sign-on for django projects only. Do you have many django apps with different users? Do you want to use only one of those apps

Erwin Feser 1 Mar 1, 2022
Django Fett is an incomplete code generator used on several projects

Django Fett Django Fett is an incomplete code generator used on several projects. This is an attempt to clean it up and make it public for consumption

Jeff Triplett 6 Dec 31, 2021
Django-environ allows you to utilize 12factor inspired environment variables to configure your Django application.

Django-environ django-environ allows you to use Twelve-factor methodology to configure your Django application with environment variables. import envi

Daniele Faraglia 2.7k Jan 7, 2023
pytest-django allows you to test your Django project/applications with the pytest testing tool.

pytest-django allows you to test your Django project/applications with the pytest testing tool.

pytest-dev 1.1k Dec 14, 2022
django-dashing is a customisable, modular dashboard application framework for Django to visualize interesting data about your project. Inspired in the dashboard framework Dashing

django-dashing django-dashing is a customisable, modular dashboard application framework for Django to visualize interesting data about your project.

talPor Solutions 703 Dec 22, 2022
Django-Audiofield is a simple app that allows Audio files upload, management and conversion to different audio format (mp3, wav & ogg), which also makes it easy to play audio files into your Django application.

Django-Audiofield Description: Django Audio Management Tools Maintainer: Areski Contributors: list of contributors Django-Audiofield is a simple app t

Areski Belaid 167 Nov 10, 2022
A Django app to initialize Sentry client for your Django applications

Dj_sentry This Django application intialize Sentry SDK to your Django application. How to install You can install this packaging by using: pip install

Gandi 1 Dec 9, 2021
A tool to automatically fix Django deprecations.

A tool to help upgrade Django projects to newer version of the framework by automatically fixing deprecations. The problem When maintaining a Django s

Bruno Alla 155 Dec 14, 2022
Get inside your stronghold and make all your Django views default login_required

Stronghold Get inside your stronghold and make all your Django views default login_required Stronghold is a very small and easy to use django app that

Mike Grouchy 384 Nov 23, 2022
DCM is a set of tools that helps you to keep your data in your Django Models consistent.

Django Consistency Model DCM is a set of tools that helps you to keep your data in your Django Models consistent. Motivation You have a lot of legacy

Occipital 59 Dec 21, 2022
Automatically reload your browser in development.

django-browser-reload Automatically reload your browser in development. Requirements Python 3.6 to 3.10 supported. Django 2.2 to 4.0 supported. Are yo

Adam Johnson 254 Jan 4, 2023
Meta package to combine turbo-django and stimulus-django

Hotwire + Django This repository aims to help you integrate Hotwire with Django ?? Inspiration might be taken from @hotwired/hotwire-rails. We are sti

Hotwire for Django 31 Aug 9, 2022
django-reversion is an extension to the Django web framework that provides version control for model instances.

django-reversion django-reversion is an extension to the Django web framework that provides version control for model instances. Requirements Python 3

Dave Hall 2.8k Jan 2, 2023
Django project starter on steroids: quickly create a Django app AND generate source code for data models + REST/GraphQL APIs (the generated code is auto-linted and has 100% test coverage).

Create Django App ?? We're a Django project starter on steroids! One-line command to create a Django app with all the dependencies auto-installed AND

imagine.ai 68 Oct 19, 2022