deps

I've exited countless Python/Django threads discussing future plans. Year -1: The community has a problem. Year 0: Proposal to fix the problem. Year 1: A small but vocal subset of the Python/Django community pops up in every thread: "It's not actually a problem." or "It's not an issue that my project would ever encounter so limited resources shouldn't be expended on it." Year 2: People are choosing other solutions because Python/Django isn't addressing the problem. Year 3: We'll form a committee. The committee doesn't think it's a problem. Year 4: The community has a problem. Fine. Why doesn't the community write a Python Enhancement Proposal/Django Enhancement Proposal (PEP/DEP)? Years 5-10: PEP/DEP ignored. Year 11: The community has a problem. PEP/DEP implemented and released. Year 12-22: Major packages refuse to support the change. Ye

I was using Redis and Celery but was not happy with the complexity. But then I found out that background workers are being implemented to Django. https://github.com/django/deps/blob/main/accepted/0014-backg... This functionality has been backported as django-tasks library. You can use the database (i.e. Postgres) as the permanent storage. For periodic jobs and running the django-tasks, I use Superchronic, which is a Docker-compatible cron. It is compatible with cron, with the added benefit that you can run jobs with sub-minute granularity. I have had no problems with running Superchronic inside my fly.io app. I run Superchronic and Django with honcho and Procfiles.

> It recently added task queues as a concept It took me a while to find any information on this, so for others: https://forum.djangoproject.com/t/django-tasks-bringing-back... https://github.com/django/deps/blob/main/accepted/0014-backg...

The full implementation text is here https://github.com/django/deps/blob/main/accepted/0014-backg... It will not match features that exist in celery, it'll focus on dispatching and enqueue.

No, as I understand it, the Django project's stance on type hints is that they aren't going to be added any time soon, but they are willing to accept small PRs that are needed by external type-checkers on a case by case basis. Details here: https://github.com/django/deps/pull/65

I believe from memory Django decided to move to using Black back in 2019 [0] but delayed the change until Black exited Beta. Black became none beta at the end of January [1]. This was finally merged to the main branch today [2]. I suspect there are lots of other both open source and private projects that are also making the change now. This is a show of confidence in Black as the standard code formatter for Python. 0: https://github.com/django/deps/blob/main/accepted/0008-black... 1: https://news.ycombinator.com/item?id=30130316 2: https://github.com/django/django/pull/15387

:) Django currently requires that every table have a _single_ primary key column. You can have a unique multi-column index, but you _also_ need to have a single primary key column, which sometimes makes working with existing databases tricky or inefficient. It's Django's oldest open ticket, from August 2005: https://code.djangoproject.com/ticket/373 The trick is how do you group those columns together in a way that stays compatible with the rest of the framework. Here's a 2015 proposal "DEP 191" for how to make it work: - https://github.com/django/deps/blob/main/draft/0191-composit... Basically, the multi-columns end up needing to be exposed as a single python object (CompositeField) to stay compatible with the rest of the framework, but do changes to the individual "subfields" on the row-object need to be kept in sync (data binding) with

There's a DEP discussion going on at https://github.com/django/deps/pull/65. Though I kind of gave up on it for now, I don't believe it'll be accepted in the current state of mypy and typing ecosystem. Try 'django-stubs' mentioned above too https://github.com/typeddjango/django-stubs, it's mostly complete. Mypy plugin inside takes care of a lot of stuff. Disclaimer: I'm a creator of the 'django-stubs'

https://www.aeracode.org/2018/06/04/django-async-roadmap/ https://github.com/django/deps/blob/master/accepted/0009-asy...

The author writes that they have a particularly big piece of maintenance coming up. > The latest change we need is an especially large amount of work, as we will have to move from Python 2 to Python 3. This sounds like the transition from Django 1.11 to (probably) Django 2.2, if they're moving from LTS to LTS, and it definitely is a big piece of work if you also have to change python versions. Django defined a release schedule DEP[0] a few years back to try to preference stability and reduce the amount of maintenance when moving between LTS versions, which is approximately every 3 years. If your application runs on an LTS version without any deprecation warnings, then you should be able to move to the next LTS version without any changes. Which is nice in theory, but 3rd party packages in particular aren't always aligned in such a nice wa

DEP 0008 ('Formatting Code with Black') was accepted by the Django board last week. They're going to wait until Black has a stable release before reformatting all the code, as there's at least one thing they don't like about how Black handles things. https://github.com/django/deps/blob/master/accepted/0008-bla... https://groups.google.com/forum/#!topic/django-developers/7G...

The author may be referring to libraries themselves having dependencies. These attitudes are changing. For example, last week the Django community published a draft proposal that declares that "Django can have dependencies". The "Background" section is a good read and helps explain the origins of these attitudes: https://github.com/django/deps/blob/master/draft/0007-depend....