A helper for organizing Django project settings by relying on well established programming patterns.

Overview

django-configurations Latest version on PyPI

GitHub Actions Codecov Documentation status Python versions Jazzband

django-configurations eases Django project configuration by relying on the composability of Python classes. It extends the notion of Django's module based settings loading with well established object oriented programming patterns.

Check out the documentation for more complete examples.

Quickstart

Install django-configurations:

pip install django-configurations

or, alternatively, if you want to use URL-based values:

pip install django-configurations[cache,database,email,search]

Then subclass the included configurations.Configuration class in your project's settings.py or any other module you're using to store the settings constants, e.g.:

# mysite/settings.py

from configurations import Configuration

class Dev(Configuration):
    DEBUG = True

Set the DJANGO_CONFIGURATION environment variable to the name of the class you just created, e.g. in bash:

export DJANGO_CONFIGURATION=Dev

and the DJANGO_SETTINGS_MODULE environment variable to the module import path as usual, e.g. in bash:

export DJANGO_SETTINGS_MODULE=mysite.settings

Alternatively supply the --configuration option when using Django management commands along the lines of Django's default --settings command line option, e.g.

python manage.py runserver --settings=mysite.settings --configuration=Dev

To enable Django to use your configuration you now have to modify your manage.py or wsgi.py script to use django-configurations's versions of the appropriate starter functions, e.g. a typical manage.py using django-configurations would look like this:

#!/usr/bin/env python

import os
import sys

if __name__ == "__main__":
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')
    os.environ.setdefault('DJANGO_CONFIGURATION', 'Dev')

    from configurations.management import execute_from_command_line

    execute_from_command_line(sys.argv)

Notice in line 10 we don't use the common tool django.core.management.execute_from_command_line but instead configurations.management.execute_from_command_line.

The same applies to your wsgi.py file, e.g.:

import os

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')
os.environ.setdefault('DJANGO_CONFIGURATION', 'Dev')

from configurations.wsgi import get_wsgi_application

application = get_wsgi_application()

Here we don't use the default django.core.wsgi.get_wsgi_application function but instead configurations.wsgi.get_wsgi_application.

That's it! You can now use your project with manage.py and your favorite WSGI enabled server.

Comments
  • "improperly installed" error when run from PyCharm, yet works on command line

    Hi,

    I am trying to use django-configurations with a Python3/Django-1.8.8project: everything works fine when run from the command line -- e.g., "python manage.py runserver" - yet fails when from inside PyCharm (env variables are set in the run settings pane) as follows:

    DJANGO_CONFIGURATION=Dev;DJANGO_SETTINGS_MODULE=myApp.settings;PYTHONUNBUFFERED=1
    

    The frameworks and interpreter are set up using a virtual environment; again, when run from the command line everything is fine.

    django-configuration is set up as follows:

    wsgi.py:

    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myApp.settings')
    os.environ.setdefault('DJANGO_CONFIGURATION', 'Dev')
    
    from configurations.wsgi import get_wsgi_application
    
    application = get_wsgi_application()
    

    manage.py:

    import os
    import sys
    
    if __name__ == "__main__":
        os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myApp.settings')
        os.environ.setdefault('DJANGO_CONFIGURATION', 'Dev')
    
        from configurations.management import execute_from_command_line
        execute_from_command_line(sys.argv)
    

    From settings:

    import os
    from configurations import Configuration, values
    
    # Quick-start development settings - unsuitable for production
    # See https://docs.djangoproject.com/en/1.8/howto/deployment/checklist/
    
    class Common(Configuration):
    #  ...lots of common settings....
    
    
    class Prod(Common):
        # SECURITY WARNING: don't run with debug turned on in production!
        DEBUG = False
        # AWS/S3 - PRODUCTION
        AWS_S3_SECURE_URLS = False       # use http instead of https
        AWS_QUERYSTRING_AUTH = False     # don't add complex authentication-related query parameters for requests
    # ... even more PROD settings... 
    
    
    
    class Dev(Common):
        DEBUG = True
        TEMPLATE_DEBUG = DEBUG
        #AWS/S3 - DEVELOPMENT
        AWS_S3_SECURE_URLS = False       # use http instead of https
        AWS_QUERYSTRING_AUTH = False     # don't add complex authentication-related query parameters for requests
    # ... development settings... 
    

    Any suggestions would be appreciated...

    Console output

    /Users/spector/Work/myApp/BackEnd/myAppSensorBackend/env/bin/python /Applications/PyCharm.app/Contents/helpers/pydev/pydevconsole.py 55302 55303
    PyDev console: starting.
    
    import sys; print('Python %s on %s' % (sys.version, sys.platform))
    import django; print('Django %s' % django.get_version())
    sys.path.extend(['/Users/spector/Work/myApp/BackEnd/myAppSensorBackend', '/Users/spector/Work/myApp/BackEnd/myAppSensorBackend/src', '/Applications/PyCharm.app/Contents/helpers/pycharm', '/Applications/PyCharm.app/Contents/helpers/pydev'])
    if 'setup' in dir(django): django.setup()
    import django_manage_shell; django_manage_shell.run("/Users/spector/Work/myApp/BackEnd/myAppSensorBackend/src")
    Python 3.5.1 (default, Jan 22 2016, 08:54:32) 
    [GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
    Django 1.8.8
    Traceback (most recent call last):
      File "<input>", line 5, in <module>
      File "/Users/spector/Work/myApp/BackEnd/myAppSensorBackend/env/lib/python3.5/site-packages/django/__init__.py", line 17, in setup
        configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)
      File "/Users/spector/Work/myApp/BackEnd/myAppSensorBackend/env/lib/python3.5/site-packages/django/conf/__init__.py", line 48, in __getattr__
        self._setup(name)
      File "/Users/spector/Work/myApp/BackEnd/myAppSensorBackend/env/lib/python3.5/site-packages/django/conf/__init__.py", line 44, in _setup
        self._wrapped = Settings(settings_module)
      File "/Users/spector/Work/myApp/BackEnd/myAppSensorBackend/env/lib/python3.5/site-packages/django/conf/__init__.py", line 92, in __init__
        mod = importlib.import_module(self.SETTINGS_MODULE)
      File "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/importlib/__init__.py", line 126, in import_module
        return _bootstrap._gcd_import(name[level:], package, level)
      File "<frozen importlib._bootstrap>", line 986, in _gcd_import
      File "<frozen importlib._bootstrap>", line 969, in _find_and_load
      File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
      File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
      File "<frozen importlib._bootstrap_external>", line 662, in exec_module
      File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
      File "/Users/spector/Work/myApp/BackEnd/myAppSensorBackend/src/myApp/settings.py", line 132, in <module>
        class Prod(Common):
      File "/Users/spector/Work/myApp/BackEnd/myAppSensorBackend/env/lib/python3.5/site-packages/configurations/base.py", line 32, in __new__
        raise ImproperlyConfigured(install_failure)
    django.core.exceptions.ImproperlyConfigured: django-configurations settings importer wasn't correctly installed. Please use one of the starter functions to install it as mentioned in the docs: http://django-configurations.readthedocs.org/
    
    
    
    
    question 
    opened by dhmspector 30
  • 0.9 Release

    0.9 Release

    This incorporates both @jrdietrick and @blueyed open PRs, bumps version to 0.9 and updates the changelog. I think give it a week for review and comment and then release a new version for christmas :)

    opened by skolsuper 26
  • using django-configuration freezes django

    using django-configuration freezes django

    Using the cookbook [1] to setup celery and django-configuration makes django freezing.

    Ctrl+C will not help but kill <PID>

    This is also described in #145

    The workaround described there is to use

    from configurations import importer
    importer.install()
    

    Using this settings make celery works again. The cookbook should point out the correct celery settings!

    [1] http://django-configurations.readthedocs.io/en/stable/cookbook/#calling-a-django-management-command

    bug docs 
    opened by gthieleb 20
  • Release version 2.3 on pypi

    Release version 2.3 on pypi

    I think its time to release a new version with support for Django 3+ and Python 3.6+


    • [x] #315
    • [x] #309
    • [x] #310
    • [x] #319
    • [x] #320
    • [x] Publish release: https://github.com/jazzband/django-configurations/releases/tag/untagged-6ba2bc9f41d4148913fc
    • [x] Get Project Lead to push to PyPI: https://github.com/jazzband/help/issues/254
    • [x] Update docs on RTD
    opened by pauloxnet 19
  • Fix optparse fallback logic in Django 1.8+

    Fix optparse fallback logic in Django 1.8+

    Disclaimer: I have read the discussions in https://github.com/jezdez/django-configurations/issues/105#issuecomment-88895512 and https://github.com/jezdez/django-configurations/commit/0ff4c7612d28036449edd4b2cf3b58ca1eded0f2, and I understand the situation this package is in. I pondered long and hard as to whether I should even open this pr.

    I completely get it; by the time I am done: root-causing this issue, learning how configurations works, learning what the Django guys were trying to do in 1.8, learning how to run tox, writing tests, and finally authoring this pr, I will have spent many hours on these three lines of diff. Hours I could have spent on "real work". I'm just fortunate -- and love (and need) this package enough! -- that my current workload happens to be light enough, and I happen to have enough caffeine, to make it happen. I fully understand that it could take hours more of time that someone doesn't have to confidently sign off on it.

    tl;dr: If there's no time to even read this pull req, let alone merge it, no hard feelings!


    OK, so here's the deal:

    Django switched from optparse to argparse in Django 1.8 for extending management commands. To ease deprecation, until Django 1.10, there's some fun shim logic in Django. It says, "If the command I'm running appends anything to its option_list (the old way), we'll still use optparse. Otherwise, we'll use argparse."

    Note that, until Django 1.10, the old optparse behavior gets checked first. In other words, if option_list is manipulated and add_arguments (the new way) is implemented, we still use optparse, and anything in add_arguments is ignored.

    That's important for configurations, because it means that we can't just, for instance, add our --configuration option to option_list up front and deal with the problem when it really gets deprecated in Django 1.10. In order to correctly wrap management commands from arbitrary packages, which may or may not have shifted over to add_arguments yet, we have to wait and see what the command does (and thus what parser we get back), and then play our hand.

    https://github.com/jezdez/django-configurations/commit/6ce3740365d92c329c1e20036266cd090d57b7c4 made an attempt at doing this, but the base.BaseCommand.option_list += configuration_options causes two problems, actually:

    1. It doesn't actually add the configuration option to the command we are running right now. We just got handed the parser, which already looked at BaseCommand.option_list. So this line only adds the option for any commands run after this. This is the subject of the test in the second commit of this pr, which fails on Django 1.8 if run without the patch in the other commit.
    2. We're touching base.BaseCommand.option_list, which is a class variable. If we now run another management command in the same Django instance (say, via call_command), we will add the --configuration option a second time. Do this enough times (three, exactly), and you'll get an OptionConflictError. I encountered this while using django-nose, which evidently runs some subcommands under its test command. This is the cause of #109, and pr #110 implements a slightly hacky but working fix, but doesn't fix problem 1 above.

    The proposed patch fixes both issues by:

    • maintaining the existing "wait and see" behavior that accommodates both mgmt commands which have and have not upgraded their argument extension
    • handling the optparse fallback case by one-off adding our argument(s) to the parser in our wrapped routine, leaving the global BaseCommand.option_list untouched

    P.S. - Using the three management commands below and then running manage.py command1 on Django 1.8 is enough to minimally repro the OptionConflictError problem. It would not be difficult to write a test to validate this doesn't happen any longer, but seemed like overkill.

    # command1.py
    class Command(BaseCommand):
    
        option_list = BaseCommand.option_list + (
            make_option('--arg1', action='store_true'),
        )
    
        def handle(self, *args, **options):
            call_command('command2')
    
    # command2.py
    class Command(BaseCommand):
    
        option_list = BaseCommand.option_list + (
            make_option('--arg2', action='store_true'),
        )
    
        def handle(self, *args, **options):
            call_command('command3')
    
    # command3.py
    class Command(BaseCommand):
    
        option_list = BaseCommand.option_list + (
            make_option('--arg3', action='store_true'),
        )
    
        def handle(self, *args, **options):
            print 'hi'
    
    ready 
    opened by jrdietrick 15
  • Can't run any command

    Can't run any command

    Django 1.5.1 django-configurations 0.2.1

    When I run any command it says:

    ImproperlyConfigured: The SECRET_KEY setting must not be empty.

    But SECRET_KEY is set in Base configuration.

    Looks like somehow it does not pick up class-based configs: when I run ./manage.py, only django commands are listed.

    opened by yunmanger1 15
  • More badges to display project properties (README)

    More badges to display project properties (README)

    These changes add a few additional badges to the README. Thus should enhance transparency and make the project on PyPI more easily acessible.

    Note that this now shows that building the docs failed. Not sure why, because building them locally doesn't fail asking for a tests/requirements.txt file. :confused:

    opened by bittner 12
  • Use CommandParser instead of LaxOptionParser in django1.8

    Use CommandParser instead of LaxOptionParser in django1.8

    @jezdez I added a django version check to use CommandParser instead of LaxOptionParser if django>=1.8. I've tested it locally, this commit closes #65. django-configurations and pytest-django tests succeed.

    opened by ghost 12
  • Can't pass options?

    Can't pass options?

    Thank you for the update. I've been looking forward to this for a while. It fixes somethings that didn't work (for me), but I figured out some work-arounds so I'm ok using the last version for now.

    So after the new update:

    % ./manage.py shell_plus --ipython
    Usage: manage.py [options]
    
    manage.py error: no such option: --ipython
    

    This is valid and works in the previous version. Basically any option passed doesn't work.

    % ./manage.py syncdb --noinput
    Usage: manage.py [options]
    
    manage.py error: no such option: --noinput
    

    Did I need to alter manage.py or anything else as I upgraded from the old version?

    Thanks, Shige

    opened by typeshige 12
  • SecretValue validation problem

    SecretValue validation problem

    Noticed this in recent HEAD version (5ece10704) in comparison to what is on PyPI.

    I have a configuration setup with a Common class (which inherits from Configuration) and then Local and Production subclasses. The Production subclass has a SecretValue like so:

    EMAIL_HOST_PASSWORD = values.SecretValue(environ_prefix=None, environ_name='SENDGRID_PASSWORD')
    

    Even when DJANGO_CONFIGURATION is set to "Local", a ValueError is being thrown that the secret value must be set. Previous versions would only throw this error if the configuration was set to "Production". It seems that when environ_name is manually set, validation occurs when it shouldn't be.

    Either the Value.__call__ code should be fixed or SecretValue should have late_binding = True by default.

    opened by russelldavies 10
  • django-configurations and django-celery > 3

    django-configurations and django-celery > 3

    Celery 2.5.x used to work with django-configurations.

    3.0 do not.

    it seem it's an issue with djcelery.loaders.

    here is the issue on their side:

    https://github.com/celery/django-celery/issues/186

    is there anyway to run configurations.importer. install() for those applications that rely on django internal importlib.import_module(self.SETTINGS_MODULE)?

    opened by jeanlucmongrain 10
  • Breaks use of `--config` arguments in management commands

    Breaks use of `--config` arguments in management commands

    If a project wants to use django-configurations then doing so precludes the use of --config (or any other shortening of --configuration) in all the management commands in the project, including those inherited from other packages.

    This appears to be due to the default behaviour of argparse.ArgumentParser, specifically the allow_abbrev argument, in combination with they way that ConfigurationImporter checks for the configuration to use from the command line -- namely by running Django's argument parser before any other arguments have been added.

    I'm hitting this with https://github.com/thread/django-lightweight-queue/, whose queue_runner command has a --config which is being hidden by this behaviour. The result of which is that queue_runner --config=./special-config.py results in an AttributeError: "Couldn't find configuration './special-config.py' in module '.settings'".

    While in some cases it may be possible to change to just not using conflicting argument names, this won't always be possible if, for example, the name comes from a separate library.

    I suspect it may be possible to fix this in django-configurations by changing ConfigurationImporter to set allow_abbrev=False in the parser it creates in check_options, though I realise this might be considered a breaking change.

    opened by PeterJCLaw 0
  • Add `mypy` plugin

    Add `mypy` plugin

    Fixes #267. Related issue in the django-stubs repo - https://github.com/typeddjango/django-stubs/issues/417

    I've also added a section to the docs describing how to use this.

    opened by mvandenburgh 1
  • django-configurations is incompatible with `modify_settings` and `override_settings` decorators

    django-configurations is incompatible with `modify_settings` and `override_settings` decorators

    # …/settings.py
    from configurations import Configuration
    
    class MyConfiguration(Configuration):
        DEBUG = False
        # …
    
    # …/test_thing.py
    from django.test import modify_settings
    
    @modify_settings(DEBUG=True)
    def test_settings():
        from django.conf import settings
    
        assert hasattr(settings, "DEBUG")
        assert settings.DEBUG
    

    Running the above test will blow up here with the error TypeError: 'bool' object is not iterable. This makes sense, looking at the code:

                try:
                    # When called from SimpleTestCase.setUpClass, values may be
                    # overridden several times; cumulate changes.
                    value = self.options[name]
                except KeyError:
                    value = list(getattr(settings, name, []))  # <-- Boom!
    

    In that context, getattr(settings, name, …) gets the value of MyConfiguration.DEBUG, which is False.

    opened by posita 1
  • Improve error related end-user experience

    Improve error related end-user experience

    In my opinion, an end-user who uses an application that was built using django-configurations should in most cases not see an unwieldy traceback, but instead a nicely formatted error detailing what went wrong and what they should do to rectify it. In this regard, the PR is not aimed at application developers, but instead aims to improve the user experience of those end-users.

    As an example, instead of a traceback, the user now receives something like this:

    Couldn't setup values of configuration Debug
        * DEBUG was given an invalid value
            - DEBUG is taken from the environment variable DJANGO_DEBUG as a BooleanValue
            - '5' was received but that is invalid
        * Value of DEBUG2 could not be retrieved from environment
            - DEBUG2 is taken from the environment variable DJANGO_DEBUG2 as a BooleanValue
    

    Additionally, this PR closes #332 because I was getting annoyed at the failing tests


    This feature is implemented by introducing our own custom exception type that is raised during Value setup and processing and caught by our importer. When caught, an error handler pretty-prints the information that is included in the exception. This information is, in turn, automatically retrieved from the relevant Value.


    THIS IS STILL A WORK IN PROGRESS because I still want to include more actionable information in the error message. Nonetheless, the PR gives others the opportunity to chime in about the feature.

    TODOs:

    • [ ] Add more information to error messages (e.g. which possible values are accepted in the environment or help texts)
    • [ ] Add automatic generation of example values where that makes sense (e.g. for django secret keys)
    • [ ] Update documentation to explain how application developers can raise their own ConfigurationErrors to display well-formatted errors to end-users, how help_text, help_reference and example_generator can be used
    • [ ] Get Code Quality up to standards (flake8 + test coverage)
    opened by ftsell 1
  • Update tests for redis and email urls

    Update tests for redis and email urls

    opened by ftsell 1
  • Stop copying parent attributes into child class

    Stop copying parent attributes into child class

    This avoids breaking the normal MRO for attributes, which searches the class hierarchy for attribute definitions. If attributes are copied onto every class in the hierarchy, the C3 MRO algorithm finds the attribute in a child class even though that class didn't actually define it, which results in surprising attribute values when classes in the hierarchy set the same attribute to different values.

    Fixes #329

    opened by RJPercival 1
Releases(2.4)
  • 2.4(Sep 1, 2022)

    What's Changed

    • Fixed #336 -- Update Python and Django versions by @pauloxnet in https://github.com/jazzband/django-configurations/pull/337
    • add GitHub URL for PyPi by @andriyor in https://github.com/jazzband/django-configurations/pull/331
    • Prepare next release 2.4 by @pauloxnet in https://github.com/jazzband/django-configurations/pull/338

    New Contributors

    • @andriyor made their first contribution in https://github.com/jazzband/django-configurations/pull/331

    Full Changelog: https://github.com/jazzband/django-configurations/compare/2.3.2...2.4

    Source code(tar.gz)
    Source code(zip)
  • 2.3.2(Jan 25, 2022)

  • 2.3.1(Nov 8, 2021)

    • Test Django 3.2 on Python 3.10 as well.

    • Test on PyPy 3.6, 3.7 and 3.8.

    • Enforce Python version requirement during installation (>=3.6).

    • Fix and refactor the documentation build process.

    Source code(tar.gz)
    Source code(zip)
  • 2.3(Oct 27, 2021)

    • BACKWARD INCOMPATIBLE Drop support for Python 2.7 and 3.5.

    • BACKWARD INCOMPATIBLE Drop support for Django < 2.2.

    • Add support for Django 3.1 and 3.2.

    • Add suppport for Python 3.9 and 3.10.

    • Deprecate utils.import_by_path in favor of django.utils.module_loading.import_string.

    • Add ASGI support.

    • Added "python -m configurations" entry point.

    • Make package install_requires include django>=2.2.

    • Prevent an ImproperlyConfigured warning from DEFAULT_HASHING_ALGORITHM.

    • Prevent warnings for settings deprecated in Django 2.2 (DEFAULT_CONTENT_TYPE and FILE_CHARSET).

    • Preserve Django warnings when DEFAULT_AUTO_FIELD is not set.

    • Miscellaneous documentation fixes.

    • Miscellaneous internal improvements.

    Source code(tar.gz)
    Source code(zip)
  • 2.1(Aug 16, 2018)

    • BACKWARD INCOMPATIBLE Drop support of Python 3.3.

    • BACKWARD INCOMPATIBLE Drop support of Django 1.9.

    • Add support for Django 2.1.

    • Add PositiveIntegerValue configuration value.

    • Fix bool(BooleanValue) to behave as one would expect (e.g. bool(BooleanValue(False)) returns False).

    • Miscellaneous documentation improvements and bug fixes.

    Source code(tar.gz)
    Source code(zip)
Dynamic Django settings.

Constance - Dynamic Django settings A Django app for storing dynamic settings in pluggable backends (Redis and Django model backend built in) with an

Jazzband 1.5k Jan 7, 2023
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
Helps working with singletons - things like global settings that you want to edit from the admin site.

Django Solo +---------------------------+ | | | | | \ | Django Solo helps

Sylvain Toé 726 Jan 8, 2023
A beginner django project and also my first Django project which involves shortening of a longer URL into a short one using a unique id.

Django-URL-Shortener A beginner django project and also my first Django project which involves shortening of a longer URL into a short one using a uni

Rohini Rao 3 Aug 8, 2021
Let AngularJS play well with Django

django-angular Let Django play well with AngularJS What does it offer? Add AngularJS directives to Django Forms. This allows to handle client side for

Jacob Rief 1.2k Dec 27, 2022
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
Dockerizing Django with Postgres, Gunicorn, Nginx and Certbot. A fully Django starter project.

Dockerizing Django with Postgres, Gunicorn, Nginx and Certbot ?? Features A Django stater project with fully basic requirements for a production-ready

null 8 Jun 27, 2022
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 Starter is a simple Skeleton to start with a Django project.

Django Starter Template Description Django Starter is a simple Skeleton to start

Numan Ibn Mazid 1 Jan 10, 2022
Intellicards-backend - A Django project bootstrapped with django-admin startproject mysite

Intellicards-backend - A Django project bootstrapped with django-admin startproject mysite

Fabrizio Torrico 2 Jan 13, 2022
Notes-Django: an advanced project to save notes in Django. where users are able to Create, Read, Update and Delete their notes.

An advanced software to keep you notes. It allows users to perform CRUD operations on theirs Notes. Was implemented Authorization and Authentication

Edilson Pateguana 1 Feb 5, 2022
This a Django TODO app project and practiced how to deploy and publish the project to Heroku

ToDo App Demo | Project Table of Contents Overview Built With Features How to use Acknowledgements Contact Overview Built With HTML CSS JS Django How

Cetin OGUT 1 Nov 19, 2021
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-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
Rosetta is a Django application that eases the translation process of your Django projects

Rosetta Rosetta is a Django application that facilitates the translation process of your Django projects. Because it doesn't export any models, Rosett

Marco Bonetti 909 Dec 26, 2022
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
django-quill-editor makes Quill.js easy to use on Django Forms and admin sites

django-quill-editor django-quill-editor makes Quill.js easy to use on Django Forms and admin sites No configuration required for static files! The ent

lhy 139 Dec 5, 2022