Re: Please don't kill the ecosystem

videoplugin" is unmaintained (not handling PR) : unable to patch the original Repo, I'd have to fork it ; and unable to push results to the original pypi name, I'd have to create a separate myvideoplugin-pkl package on Pypi... that's quite some hassle for (often) a 10-lines patch. Th

Fate of sql* management commands

Hello all, I've noticed that all sql* commands that were in django core management have disappeared from the latest sources. However, even though Django now has builtin south-style migrations now, these *sql** commands (especially sql-all) were priceless to debug differences between the

Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

iting code > to be removed from Django would be a significant overhead in complexity and > be a drag on the ability to evolve the framework. > > About testing, can you give an example of a problem that wasn't detected > by our current approach? I'm unsure what problem your suggestion

Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

ated aspects of the > framework)." I don't understand your complaint about the current way we're > testing deprecation warnings. > > On Saturday, January 7, 2017 at 3:17:06 PM UTC-5, Pkl wrote: >> >> >> Hello, >> >> I've *at last* had some time t

Presenting DCP, a compatibility layer for Django (feedback welcome)

Hello, I've *at last* had some time to experiment with the idea I had thrown years again, of a system to workaround the recurring breakages introduced by new django releases, breakages which sometimes lead to unreconcilable requirements between django apps. After a sprint at PyconFR, with a

Re: Django Async DEP

Hello, I'm a little late to the party, thanks for the big overview on this complex matter. There are lots of thinks I still don't understand though, for example regarding "what it unlocks". What asyncio structures would allow to run several DB queries concurrently safely and easily, that

Re: Discussing improvements of django.setup()

01.07.19 um 23:24 schrieb Pkl: > > > > Regarding django.setup() tweakability, the generic need is simply to > > have a hook, somewhere for users to put early init code, regardless of > > the way django is launched. Code that needs to execute this early are > &

Re: Ideas for a new DEP on long-term Django API compatibility

Hello everyone, (apologies in advance for the long post, but there are lots of aspects to dig here, it's not for the pleasure of writing but a necessary to progress on the relevance of a DEP) *"As you can see, there's more than "blinding self-absorption" and "harmful psychological bias"

Re: [Feature Request][Model, ORM] Disabling a field before removal to support continuous delivery

Just for reference, here is a package I crossed recently and which has an approach for that : https://github.com/3YOURMIND/django-deprecate-fields On Monday, June 24, 2019 at 3:15:04 PM UTC+2, Matthieu Rudelle wrote: > > Hi there, > > I can't find any previous ticket proposing a solution to

Discussing improvements of django.setup()

Hello everyone, I'm bringing here, for broader review and discussion, the subject of making django setup more "tweakable": https://code.djangoproject.com/ticket/30536 https://github.com/django/django/pull/11435 There is indeed a need for doing pre/post operations at that crucial moment of the

Re: Discussing improvements of django.setup()

th a workaround (monkey-patching, > probably) > - Here's what the code would look like with the improvement I'm asking for > (hopefully much better) > - Here are the alternatives I considered and why I rejected them > - Other use cases also include Y and Z > > I'm asking this because conc

Re: [Feature Request][Model, ORM] Disabling a field before removal to support continuous delivery

, It's an interesting way to solve it. We might give it a try. > > On Thursday, June 27, 2019 at 11:12:16 PM UTC+2, Pkl wrote: >> >> Just for reference, here is a package I crossed recently and which has an >> approach for that : https://github.com/3YOURMIND/django-deprecat

Ideas for a new DEP on long-term Django API compatibility

Hello everyone, I'm planning on writing a PEP on long-term API stability for Django. Most of the rationale behind this kind of commitment is described here : https://www.freecodecamp.org/news/api-stability-is-cheap-and-easy/ The idea is that the django ecosystem has suffered a lot, over the

Re: Django LTS support time

Hello Uri, my (unsurprising) two cents: this is less a problem with the time span of the LTS version, than of the API stability / upgrade ease / django compatibility (recently discussed in this thread ). In the current

Re: Ideas for a new DEP on long-term Django API compatibility

Hello Luke, thanks for your comments, mine are below On Thursday, August 1, 2019 at 10:34:22 AM UTC+2, Luke Plant wrote: > > Hi Pascal, > > I know this is a very late reply, but there have been some things going > round my head that I thought I should get down. > > *First,* some positive

Re: Discussing improvements of django.setup()

Hello, any news about this issue? Concerning the thread-safety of setup(), the PR is here - https://github.com/django/django/pull/11440 Concerning the tweakability of setup(), I don't get your argument Aymeric: "*One more or one less monkey patch isn't going to make a difference to these