As I said in my original post, I *do not propose to change the behavior of Django with respect to namespace packages*. My proposal only makes the check for them more specific so that we permit *regular* packages run from Python environments that do not set __file__.
On Tuesday, December 22, 2020 at 10:55:01 AM UTC-6 Adam Johnson wrote: > I've hit several problems with PEP-420 namespace packages in the last few > months, which inspired me to create flake8-no-pep420: > https://pypi.org/project/flake8-no-pep420/ . In summary, I found pep-420 > namespace packages are not checked by Django's test runner, coverage.py, or > mypy (with its bonus flag --namespace-packages). I imagine other code tools > fail to import them too. > > I would be inclined to stick with the previous decision unless you can > prove there's a great reason to support migrations in namespace packages -- > other than a distaste for blank __init__.py files. I can't imagine you > actually want to split one app's migrations into several separate file > system directories, do you? > > On Tue, 22 Dec 2020 at 15:58, William Schwartz <wksch...@gmail.com> wrote: > >> Django developers, >> >> The migration loader currently loads migrations only from apps whose >> migrations package has a __file__ >> <https://docs.python.org/3/reference/import.html#__file__> attribute. >> The reason for this check, given both in the source code comments >> <https://github.com/django/django/blob/2a76f4313423a3b91caade4fce71790630ef9152/django/db/migrations/loader.py#L91-L95> >> >> and in discussions among maintainers >> <https://groups.google.com/g/django-developers/c/GVHMH2ciAnk/m/vbIPbZuSBQAJ>, >> >> is to discourage the use of PEP-420 >> <http://www.python.org/dev/peps/pep-0420/> namespace packages. >> >> Without affecting that behavior, I propose to permit migrations run from >> Python environments that do not provide even *regular* packages with a >> __file__ <https://docs.python.org/3/reference/import.html#__file__> >> attribute. (This falls under the general umbrella of #30950 >> <https://code.djangoproject.com/ticket/30950>, which describes these >> environments a little.) The required change is just a few lines. >> >> If this proposal is something you would consider, I will submit a Trac >> ticket laying out further details, including citations to Python >> documentation that justifies my approach. I will simultaneously submit a PR >> with the change and a test. Documentation changes are not likely necessary, >> but I can add some if desired. >> >> I would love for this feature to land in 3.2 before the feature-freeze >> date, and can do all the work for it if a Django committer can review and >> merge the PR. >> >> Best, >> William Schwartz >> >> -- >> 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. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/1c2cb975-0f78-4ef9-a025-303dcb17a5aen%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/1c2cb975-0f78-4ef9-a025-303dcb17a5aen%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > Adam > -- 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/1e41bb54-3502-4508-9f67-262db28fc5f4n%40googlegroups.com.
