Utility for working with recurring dates in Django.

Overview

django-recurrence

Build Status

django-recurrence is a utility for working with recurring dates in Django. Documentation is available at https://django-recurrence.readthedocs.org/.

It provides:

  • Recurrence/Rule objects using a subset of rfc2445 (wraps dateutil.rrule) for specifying recurring date/times;
  • RecurrenceField for storing recurring datetimes in the database;
  • JavaScript widget.

RecurrenceField provides a Django model field which serializes recurrence information for storage in the database.

For example - say you were storing information about a university course in your app. You could use a model like this:

import recurrence.fields

class Course(models.Model):
    title = models.CharField(max_length=200)
    start = models.TimeField()
    end = models.TimeField()
    recurrences = recurrence.fields.RecurrenceField()

You'll notice that I'm storing my own start and end time. The recurrence field only deals with recurrences not with specific time information. I have an event that starts at 2pm. Its recurrences would be "every Friday". For this to work, you'll need to put the recurrence application into your INSTALLED_APPS

Running the tests

Our test coverage is currently fairly poor (we're working on it!), but you can run the tests by making sure you've got the test requirements installed:

pip install -r requirements_test.txt

Once you've done that, you can run the tests using:

make test

You can generate a coverage report by running:

make coverage

You can run tests on multiple versions of Python and Django by installing tox (pip install tox) and running:

tox
Comments
  • Flexible handling of dtstart incl. documentation

    Flexible handling of dtstart incl. documentation

    As stated by @jpulec in #90 dtstart is handled according to RFC 2445 so that it always counts as the first occurrence regardless of your pattern, like when used with between(). This causes confusion for some users (e.g. #36, #50, #71) because it is in conflict with how dateutil.rrule handles dtstart.

    With this pull request I suggest a solution which consists of:

    1. The addition of an optional parameter include_dtstart which can be either passed to a RecurrenceField or a Recurrence instance. With include_dtstart=False the default behavior does not occur for the field/object so that dtstart no longer finds its way into the occurrence list if it does not match your recurrence pattern. Because the default behavior doesn't change if include_dtstart is not specified backward compatibility is ensured.

    2. A clear documentation of how django-recurrence handles dtstart and how it can be controlled with the feature described above. In that way further confusion should be prevented.

    3. Some additional unit test cases.

    Enhancement Changes Needed 
    opened by denisiko 21
  • Widget js is raising errors

    Widget js is raising errors

    Using the minimal Course model from the docs, I've created the following template, and a suitable create view and model form to match:

    <!DOCTYPE html>
    <html lang="en_US">
    <head>
      {{ form.media }}
    </head>
    
    <body>
      <h1>Create Course</h1>
    
      <form action="" method="post">{% csrf_token %}
        {{ form.as_p }}
        <input type="submit" value="Submit" />
      </form>
    </body>
    </html>
    

    However, when actually accessing this view, I see these three errors show up in Firebug, and the recurrence field is rendered as just a plain text input.

    ReferenceError: django is not defined
        if (!django.catalog) {
    ReferenceError: gettext is not defined
        'inclusion': gettext('including'), 'exclusion': gettext('excluding')
    TypeError: recurrence.display.labels is undefined
        recurrence.display.labels.add_rule, {
    

    This is using django-recurrence==1.0.3, pip installed from PyPI.

    opened by jbradberry 19
  • How Does this Library Handle dtstart?

    How Does this Library Handle dtstart?

    It isn't stated clearly in the docs anywhere, and it seems like there are conflicting opinions in both how this library handles dtstart. In the docstrings for base.py and Recurrence it does seem to indicate that dtstart is handled the according the RFC 2445, which uses it as both the starting point for recurrences and as the first recurrence returned.

    This is in contrast to how dateutil.rrule handles it, which just uses dtstart as the starting point for recurrences and does not automatically add it as the first occurrence.

    It looks like this can be a bit of a pain point for users. #50 #36

    Should this be better documented somewhere, to explicitly state that it doesn't follow the way dateutil.rrule handles dtstart and follows more closely to the spec. Or should changing the behavior be considered since it appears to cause issues? I recognize that this would be a big change.

    opened by jpulec 15
  • change default dtstart to midnight and annual/bymonth recurrence to DAILY

    change default dtstart to midnight and annual/bymonth recurrence to DAILY

    Not sure what you think of these changes.

    The first commit makes it easier to test rulesets for a particular date by specifying the default time as (0,0) (instead of whatever now() was when the rule was created).

    The second commit makes it possible to test whether a datetime exists within an annual recurrence when only the month (but not a specific day of the month) is selected. I think this is more transparent to the user, since otherwise the particular date of the recurrence on a given month is hidden.

    Review on Reviewable

    opened by yekibud 14
  • Add start date in a rule in admin widget

    Add start date in a rule in admin widget

    Hi,

    i want to set event recurrences in the admin widget with a start date but i dont find how to do this, start date of my rules automatically take a datetime.now()

    from datetime import datetime
    import recurrence
    
    
    myrule = recurrence.Rule(
        recurrence.DAILY
    )
    
    pattern = recurrence.Recurrence(
        dtstart=datetime(2015, 10, 2, 0, 0, 0),
        dtend=datetime(2015, 10, 9, 0, 0, 0),
        rrules=[myrule, ]
    )
    

    It thats i want, i got an event started a 2october with daily recurences to 9 october, i check to python dateutil and its easy to do this directly with it too. In your app i really enjoy the admin widget, my users can easy enter complex recursive events with it, but if they can't set a start date will difficult.

    in recurrence.fields we can see this : " Field that stores a recurrence.base.Recurrence object to the database."

    Ok i go in base.Recurrence i see this :

    `dtstart` : datetime.datetime
            Optionally specify the first occurrence. This defaults to
            `datetime.datetime.now()` when the occurrence set is
            generated.
    

    Im in this case, it generate me an automatic start date.

    In recurrences.forms.RecurrenceField :

    `accept_dtstart` : bool
                Whether to accept a dtstart value passed in the input.
    

    Im really confuse, how to set a dtstart in the input?

    Thanks for your help

    opened by V1ce 13
  • Recurrence only working in Admin but buttons don't do anything when I use it in Model Form

    Recurrence only working in Admin but buttons don't do anything when I use it in Model Form

    Django admin has been fully functional with the package. However, when I tried to integrate it into a model form, the buttons don't do anything when I click them... Any help on this would be great because I've been stuck on this issue for days now with no luck!

    opened by wolfhound115 12
  • Fix timezone problems in django admin widget

    Fix timezone problems in django admin widget

    tl;dr: I think it fixes the problem that #71 is trying to address, but in a simpler and more idiomatic way.

    What is the problem?

    My browser is in timezone GMT+2. If I select the 15th of October in the widget, the Javascript in the current implementation will create the following datetime object:

    2017-10-15T00:00+02:00

    This is midnight in my timezone, but in UTC, this is actually still 10pm on the 14th! Now, somewhere on the way to the django database, the timezone information gets stripped away and what is stored is the time in UTC, without saying that it is UTC:

    2017-10-14T22:00

    Clearly, this is a bug because we are on the wrong date: 14th of October instead of 15th.

    As far as I can see convention of this library appears to be that we store the timezone-agnostic date by storing a timezone-agnostic datetime with the time set to midnight. This result is clearly violating this convention.

    How does this PR fix this?

    This PR fixes it by making sure that the widget creates the following datetime object instead:

    2017-10-15T02:00+02:00

    This is 2 am in my timezone, but in UTC, this is actually midnight

    So, when the timezone information gets stripped during form submission, the resulting timezone-agnostic datetime that ends up in the database is

    2017-10-15:00:00

    The 15th is the date that the user clicked. Since we are operating timezone-agnostic, this is all we can ask for. Happy end :)

    opened by KonstantinSchubert 10
  • Fixes #87

    Fixes #87

    This is my attempt at fixing this long-standing issue. It works for my needs without issues so far. I've utilized MutationObserver for observing DOM node additions. And replaced Django render method with a javascript initialization instead.

    opened by pasevin 9
  • Declare dependency on the admin's jQuery.js

    Declare dependency on the admin's jQuery.js

    Without this change, the admin loads recurrence-widget.init.js before jquery.init.js. As a consequence, the django.jQuery variable isn't created yet and the following error happens:

    Uncaught TypeError: django.jQuery is not a function at recurrence-widget.init.js:1
    

    With this change, the admin loads JS scripts in the correct order.

    Refs #142.

    opened by aaugustin 8
  • Will there be any support for django 2.2 and above?

    Will there be any support for django 2.2 and above?

    Do you plan on any updates so that current versions of django will be supported? I have been trying and hoping to get this to work with 2.2 and just re-read the documentation to find this...

    Currently, django-recurrence supports Python 2.7, Python 3.3, Python 3.4 and Python 3.5.
    
    django-recurrence works with Django from versions 1.7 to 1.11.
    

    It appears that {{form.media}} is loading enough to create the textarea but that is it.

    Screenshot from 2019-06-18 18-30-28

    Screenshot from 2019-06-18 18-31-56

    opened by apowell656 8
  • Passing a null value to RecurrenceField will cause a TypeError

    Passing a null value to RecurrenceField will cause a TypeError

    At this point in the code https://github.com/django-recurrence/django-recurrence/blob/master/recurrence/forms.py#L147 if the value you passed is None it will throw a TypeError, saying it expected a string or a buffer. Maybe a check should be done, if value is None then value = '' the empty string

    opened by audiolion 8
  • Bump sphinx from 4.3.2 to 6.1.1

    Bump sphinx from 4.3.2 to 6.1.1

    Bumps sphinx from 4.3.2 to 6.1.1.

    Release notes

    Sourced from sphinx's releases.

    v6.1.1

    Changelog: https://www.sphinx-doc.org/en/master/changes.html

    v6.1.0

    Changelog: https://www.sphinx-doc.org/en/master/changes.html

    v6.0.1

    Changelog: https://www.sphinx-doc.org/en/master/changes.html

    v6.0.0

    Changelog: https://www.sphinx-doc.org/en/master/changes.html

    v6.0.0b2

    Changelog: https://www.sphinx-doc.org/en/master/changes.html

    v6.0.0b1

    Changelog: https://www.sphinx-doc.org/en/master/changes.html

    v5.3.0

    Changelog: https://www.sphinx-doc.org/en/master/changes.html

    v5.2.3

    Changelog: https://www.sphinx-doc.org/en/master/changes.html

    v5.2.2

    Changelog: https://www.sphinx-doc.org/en/master/changes.html

    v5.2.1

    Changelog: https://www.sphinx-doc.org/en/master/changes.html

    v5.2.0

    Changelog: https://www.sphinx-doc.org/en/master/changes.html

    v5.1.1

    Changelog: https://www.sphinx-doc.org/en/master/changes.html

    v5.1.0

    Changelog: https://www.sphinx-doc.org/en/master/changes.html

    v5.0.2

    Changelog: https://www.sphinx-doc.org/en/master/changes.html

    v5.0.1

    Changelog: https://www.sphinx-doc.org/en/master/changes.html

    v5.0.0

    No release notes provided.

    v5.0.0b1

    Changelog: https://www.sphinx-doc.org/en/master/changes.html

    ... (truncated)

    Changelog

    Sourced from sphinx's changelog.

    Release 6.1.1 (released Jan 05, 2023)

    Bugs fixed

    • #11091: Fix util.nodes.apply_source_workaround for literal_block nodes with no source information in the node or the node's parents.

    Release 6.1.0 (released Jan 05, 2023)

    Dependencies

    Incompatible changes

    • #10979: gettext: Removed support for pluralisation in get_translation. This was unused and complicated other changes to sphinx.locale.

    Deprecated

    • sphinx.util functions:

      • Renamed sphinx.util.typing.stringify() to sphinx.util.typing.stringify_annotation()
      • Moved sphinx.util.xmlname_checker() to sphinx.builders.epub3._XML_NAME_PATTERN

      Moved to sphinx.util.display:

      • sphinx.util.status_iterator
      • sphinx.util.display_chunk
      • sphinx.util.SkipProgressMessage
      • sphinx.util.progress_message

      Moved to sphinx.util.http_date:

      • sphinx.util.epoch_to_rfc1123
      • sphinx.util.rfc1123_to_epoch

      Moved to sphinx.util.exceptions:

      • sphinx.util.save_traceback

    ... (truncated)

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 0
  • Bump tox from 3.25.1 to 4.2.4

    Bump tox from 3.25.1 to 4.2.4

    Bumps tox from 3.25.1 to 4.2.4.

    Release notes

    Sourced from tox's releases.

    4.2.4

    What's Changed

    Full Changelog: https://github.com/tox-dev/tox/compare/4.2.3...4.2.4

    4.2.3

    What's Changed

    Full Changelog: https://github.com/tox-dev/tox/compare/4.2.2...4.2.3

    4.2.2

    What's Changed

    Full Changelog: https://github.com/tox-dev/tox/compare/4.2.1...4.2.2

    4.2.1

    What's Changed

    New Contributors

    Full Changelog: https://github.com/tox-dev/tox/compare/4.2.0...4.2.1

    4.2.0

    What's Changed

    Full Changelog: https://github.com/tox-dev/tox/compare/4.1.3...4.2.0

    4.1.3

    What's Changed

    ... (truncated)

    Changelog

    Sourced from tox's changelog.

    v4.2.4 (2023-01-05)

    Bugfixes - 4.2.4

    - Setting ``[testenv] basepython = python3`` will no longer override the Python interpreter version requested by a factor,
      such as ``py311`` - by :user:`stephenfin`. (:issue:`2754`)
    - Also accept tab after colon before factor filter expansion - by :user:`pdecat`. (:issue:`2823`)
    

    v4.2.3 (2023-01-04)

    Bugfixes - 4.2.3

    • devenv does not respect the specified path when the package is a wheel file - by :user:gaborbernat. (:issue:2815)
    • Require space after colon before factor filter expansion, unless it is the last character of the line - by :user:pdecat. (:issue:2822)

    v4.2.2 (2023-01-04)

    Bugfixes - 4.2.2

    - Add ``CC``, ``CFLAGS``, ``CCSHARED``, ``CXX``, ``CPPFLAGS``, ``LDFLAGS``, ``PKG_CONFIG`` and ``PKG_CONFIG_SYSROOT_DIR``
      to the default passed through environment variables list as these are needed for building various C-extensions
      - by :user:`gaborbernat`. (:issue:`2818`)
    

    v4.2.1 (2023-01-03)

    Bugfixes - 4.2.1

    • Fix extracting extras from markers with more than 2 extras in an or chain - by :user:dconathan. (:issue:2791)

    v4.2.0 (2023-01-03)

    Features - 4.2.0

    - Packaging environments now inherit from the ``pkgenv`` section, allowing to set all your packaging options in one place,
      and support the ``deps`` key to set additional dependencies that will be installed after ``pyproject.toml`` static
      ``requires`` but before backends dynamic requires - by :user:`gaborbernat`. (:issue:`2543`)
    

    Improved Documentation - 4.2.0

    • Document breaking changes with tox 4 and packaging environments - by :user:gaborbernat. (:issue:2543)
    • Document how to handle environments whose names match tox subcommands - by :user:sirosen. (:issue:2728)

    ... (truncated)

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 0
  • Remove use of deprecated ‘distutils’ library

    Remove use of deprecated ‘distutils’ library

    Python versions from 3.10 onward deprecate use of ‘distutils’ (in PEP 632), and it will be removed from Python 3.12.

    This project should remove the option for ‘distutils’, and commit to use only the recommended ‘setuptools’ for building the package.

    opened by bignose-debian 1
  • Saving in 'UTC' problem with DST

    Saving in 'UTC' problem with DST

        I don't know if #191 solves the problem.
    

    Imagine this: server timezone is 'UTC', and user's timezone is 'Europe/Berlin' (+01:00 or +02:00 depending on the time of the year). Let's say user needs daily occurrences between 29.10. and 2.11. at 16:00h. User is creating a recurrence on 26.10. when his timezone is +02:00 compared to UTC. Current implementation will save dtstart as 14:00 UTC. And as result user would get next occurrences: 2022-10-29 14:00 UTC => 2022-10-17 16h Europe/Berlin (+02:00) 2022-10-30 14:00 UTC => 2022-10-17 16h Europe/Berlin (+02:00) 2022-11-01 14:00 UTC => 2022-10-17 15h Europe/Berlin (+01:00) 2022-11-02 14:00 UTC => 2022-10-17 15h Europe/Berlin (+01:00)

    Because once the time is converted to UTC we don't know which time user wanted.

    https://webis.helpshift.com/hc/en/3-pocket-informant/faq/177-recurring-events-and-daylight-saving-time-1634048685/

    it should follow rule of the "creation" time zone, not server/UTC timezone,

    Originally posted by @bonokl in https://github.com/jazzband/django-recurrence/issues/174#issuecomment-1325149005

    one of the possible ideas can be some kind of setting attribute where user can decide whether to save all data as UTC or as it is

    opened by bonokl 0
  • Bump flake8 from 4.0.1 to 6.0.0

    Bump flake8 from 4.0.1 to 6.0.0

    Bumps flake8 from 4.0.1 to 6.0.0.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 1
  • Bump pytest-sugar from 0.9.5 to 0.9.6

    Bump pytest-sugar from 0.9.5 to 0.9.6

    Bumps pytest-sugar from 0.9.5 to 0.9.6.

    Changelog

    Sourced from pytest-sugar's changelog.

    0.9.6 (2022-11-5) ^^^^^^^^^^^^^^^^^^^

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 1
Releases(1.11.1)
🔥 Campus-Run Django Server🔥

🏫 Campus-Run Campus-Run is a 3D racing game set on a college campus. Designed this service to comfort university students who are unable to visit the

Youngkwon Kim 1 Feb 08, 2022
Build reusable components in Django without writing a single line of Python.

Build reusable components in Django without writing a single line of Python. {% #quote %} {% quote_photo src="/project-hail-mary.jpg" %} {% #quot

Mitchel Cabuloy 277 Jan 02, 2023
Django API without Django REST framework.

Django API without DRF This is a API project made with Django, and without Django REST framework. This project was done with: Python 3.9.8 Django 3.2.

Regis Santos 3 Jan 19, 2022
GeoDjango provides geospatial extensions to the Django web dev framework

Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. All documentation is in the "docs" directo

Paul Smith 20 Sep 20, 2022
Dashboad Full Stack utilizando o Django.

Dashboard FullStack completa Projeto finalizado | Informações Cadastro de cliente Menu interatico mostrando quantidade de pessoas bloqueadas, liberada

Lucas Silva 1 Dec 15, 2021
Django Pickled Model

Django Pickled Model Django pickled model provides you a model with dynamic data types. a field can store any value in any type. You can store Integer

Amir 3 Sep 14, 2022
An orgizational tool to keep track of tasks/projects and the time spent on them.

Django-Task-Manager Task Tracker using Python Django About The Project This project is an orgizational tool to keep track of tasks/projects and the ti

Nick Newton 1 Dec 21, 2021
A Django app that creates automatic web UIs for Python scripts.

Wooey is a simple web interface to run command line Python scripts. Think of it as an easy way to get your scripts up on the web for routine data anal

Wooey 1.9k Jan 08, 2023
Forward and backwards compatibility layer for Django 1.4, 1.7, 1.8, 1.9, 1.10, and 1.11

django-compat Forward and backwards compatibility layer for Django 1.4 , 1.7 , 1.8, 1.9, 1.10 and 1.11 Consider django-compat as an experiment based o

arteria GmbH 106 Mar 28, 2022
A small and lightweight imageboard written with Django

Yuu A small and lightweight imageboard written with Django. What are the requirements? Python 3.7.x PostgreSQL 14.x Redis 5.x FFmpeg 4.x Why? I don't

mint.lgbt 1 Oct 30, 2021
Use watchfiles in Django’s autoreloader.

django-watchfiles Use watchfiles in Django’s autoreloader. Requirements Python 3.7 to 3.10 supported. Django 2.2 to 4.0 supported. Installation Instal

Adam Johnson 43 Dec 14, 2022
Django web apps for managing schedules.

skdue Description Skdue is a web application that makes your life easier by helping you manage your schedule. With the ability which allows you to cre

Patkamon_Awai 1 Jun 30, 2022
The new Python SDK for Sentry.io

Bad software is everywhere, and we're tired of it. Sentry is on a mission to help developers write better software faster, so we can get back to enjoy

Sentry 1.4k Jan 05, 2023
Packs a bunch of smaller CSS files together from 1 folder.

Packs a bunch of smaller CSS files together from 1 folder.

1 Dec 09, 2021
Hello world written in Django.

Learning Django 💡 create a virtual environment create python -m venv ./venv. this virtualenv file will be excluded by .gitignore activate the virtual

Dipak giri 4 Nov 26, 2021
Full control of form rendering in the templates.

django-floppyforms Full control of form rendering in the templates. Authors: Gregor Müllegger and many many contributors Original creator: Bruno Renié

Jazzband 811 Dec 01, 2022
Django query profiler - one profiler to rule them all. Shows queries, detects N+1 and gives recommendations on how to resolve them

Django Query Profiler This is a query profiler for Django applications, for helping developers answer the question "My Django code/page/API is slow, H

Django Query Profiler 116 Dec 15, 2022
Django-powered application about blockchain (bitcoin)

Django-powered application about blockchain (bitcoin)

Igor Izvekov 0 Jun 23, 2022
🔃 A simple implementation of STOMP with Django

Django Stomp A simple implementation of STOMP with Django. In theory it can work with any broker which supports STOMP with none or minor adjustments.

Juntos Somos Mais 32 Nov 08, 2022
The uncompromising Python code formatter

The Uncompromising Code Formatter “Any color you like.” Black is the uncompromising Python code formatter. By using it, you agree to cede control over

Python Software Foundation 30.7k Jan 03, 2023