Hi I have survived a few changes in Django over the last >10 years, and this change is absolutely not comparable to any of the problematic ones.
For example, the get_query_set -> get_queryset rename was hard because it was unclear how to properly support subclassing querysets. The on_delete addition was terrible because everything had to be edited by hand. The time investment is significant even after upgrading dozens of sites. The proposed rename can be achieved in projects with a relatively straightforward invocation of "git grep --name-only domain_whitelist | xargs sed -i -e s/ domain_whitelist/ domain_allowlist/g". We don't have to add new arguments by hand or think about subclassing. In my opinion 1) really is fine in this case. Yes, it will also need a little bit of time to update this, but it'll be a blip compared to other problems I'll encounter when the next upgrade comes around. Thanks, Matthias On Thu, Jun 18, 2020 at 5:10 PM Carlton Gibson <carlton.gib...@gmail.com> wrote: > Hi All, > > We merged the docs changes remove whitelisted &co last week. > https://github.com/django/django/pull/13031 > > There's a PR now ready to adjust EmailValidator to use domain_allowlist. > https://github.com/django/django/pull/13079/ > > This is all fine *except* it will require editing any historical > migrations that feature EmailValidator, using the `domain_whitelist` > attribute, since validators are serialized in migrations. > > * Thinking of in user projects, and any third-party apps. > * An affected third-party would need to think about timing of a change, > support say 2.2 until EOL. ... > * Suspecting total number of affected lines is low, but not zero. > * To begin there's a deprecation period, so plenty of warning, but asking > people to edit old migrations is not ideal shall we say. > > (Hopefully that's not too terse.) > > Options: > > > *1. Bite the bullet. * > > I'm not too keen on this: `on_delete=models.CASCADE`. > In the 1.9 release notes there was, "Update models and existing migrations > to explicitly set the argument." > It was horrible. > > The scale here is not anything like the same but... > > > *2. Don't remove the whitelist kwarg. * > > We could just leave it forever, undocumented, commented in the code as > just an alias to the new domain_allowlist. > > If we did this, there's a question as to whether we'd have a warning for > the kwarg during the deprecation period? > (If we did, we'd remove the warning, but not the actual kwarg.) > > This is horrible too, but given 1 I think we have to consider it. > > > *3. Some kind of script to make the changes for us. * > > So I see django-codebump just came up in the BigAutoField thread. Similar > came up in the Remove url() thread recently. > > What's the state of play here? Are we in a position (by 3.2) to ship a > utility to (*inter alia*) automate updating historical migrations? > Without having looked into it, this seems like a small, well scoped > problem, that would make a good test case for such a tool. > > In theory this is better that 1 or 2, but is it feasible? > > Thoughts? > > Thanks. > Carlton. > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/05567701-5721-469b-830b-11da4f116d4bo%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/05567701-5721-469b-830b-11da4f116d4bo%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANvPqgBJF-weRiYqE5fMwWO1eV02oVwmqDgQPRBo5itynBycww%40mail.gmail.com.
