Re: Removing aliased imports ("from") in generated migration files to prevent conflicts

Django doesn't depend on flake8, so it can't be used during migration generation. Otherwise, I think aliasing the conflicting modules (6) is indeed a better way. The problem came about on #django IRC channel because someone named an app "settings", presumably to store some configuration. --

Re: Removing aliased imports ("from") in generated migration files to prevent conflicts

There's a 6th way, which is to alias the probematic modules rather than django's modules, e.g. from django.db import models import models as models_ ... Field( default=models_.my_default ) ... There's also a 7th way, which is to use flake8 which will, with its default config, complain

Re: Removing aliased imports ("from") in generated migration files to prevent conflicts

There may be a 5th way, which would be to make an alias under the clash conditions. from django.db import models as django_models However this could also lead to mistakes in assume the django models would still be called models. On 9 Jan 2017 21:59, "Alexey Kotlyarov"

Removing aliased imports ("from") in generated migration files to prevent conflicts

As stated in https://code.djangoproject.com/ticket/26099, it is possible for a project with an unfortunately named application to result in a migration file being generated which will raise an error on attempting to migrate, without any prior warning. The problem is that the following imports