sqlparse is already installed as part of Django's tests. The question is whether sqlparse should be mandatory for SQLite users (i.e. when getting started with a new project an error message will say, "You must install sqlparse to use SQLite" (I don't think there's a way to install it automatically unless we install it for all users, regardless of database) or if we should try to make it optional and only raise an error if a project's migrations require it.
The question is "what percentage of SQLite projects are going to end up needing sqlparse based on their migrations? If it's high enough, it might make for a better user experience to have users install it when they're getting started instead of a lazy error when get_constraints() is called." On Monday, October 8, 2018 at 3:22:32 AM UTC-4, Andrew Godwin wrote: > > Adding sqlparse into the introspection code for SQLite specifically means > it's going to be a runtime dependency for anything to do with migrations. > > I'm alright having that be the case, but I do think we should make sure > the tests run with SQLite as otherwise a large section of the most > complicated code in migrations won't be tested properly. > > Andrew > > > On Mon, 8 Oct 2018, 00:59 Ian Foote, <i...@feete.org <javascript:>> wrote: > >> Hi all, >> >> On my pull request (https://github.com/django/django/pull/10406) >> refactoring how Django creates database constraints I introduced a >> dependency on sqlparse in the sqlite introspection code. This allows Django >> to correctly read information about constraints on sqlite, particularly the >> name. >> >> When reviewing ( >> https://github.com/django/django/pull/10406#issuecomment-424542217) Tim >> Graham raised the question of whether we should make sqlparse a mandatory >> requirement for the sqlite tests or if we should skip those tests that >> require it. In later discussion ( >> https://github.com/django/django/pull/10406#issuecomment-427362983), Tim >> raised the point that the introspection code is used by migrations. >> >> I'm not clear myself what the best route forwards here is, so I'm >> bringing it to Django Developers for discussion (as Tim suggested). >> >> Thanks, >> Ian >> >> -- >> 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-develop...@googlegroups.com <javascript:>. >> To post to this group, send email to django-d...@googlegroups.com >> <javascript:>. >> Visit this group at https://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAFv-zfKadOeWit8M6GMmx4H2ChUCU6u%3DscHX8F7oBKJkHRbuVg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/django-developers/CAFv-zfKadOeWit8M6GMmx4H2ChUCU6u%3DscHX8F7oBKJkHRbuVg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9a5822a0-18c7-4fef-b1d6-b09e9bb63805%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
