To me it seems the choice of doing migrations for app/model should be done by the author of the app.
How about model/app level setting migrations_mode, where the choices are auto, manual and never. Auto is the defaul and behaves like current Django. Manual means that you'll have to mention the app explicitly for makemigrations. This would be a good default for Django's apps and for 3rd party apps. Finally never disables migrations for the app entirely, both creation and applying of migrations. - Anssi On Sunday, July 19, 2015, Shai Berger <s...@platonix.com> wrote: > On Friday 17 July 2015 19:48:30 Carl Meyer wrote: > > On 07/17/2015 10:38 AM, Marcin Nowak wrote: > > > Sounds enough good. One important thing for me is that I have many of > > > external apps and few in project managed by me. Reconfiguring most of > > > apps just to tell Django "leave them alone" sounds like an overhead. > > > That's why I would like to tell Django "here are my apps, manage them > > > please". > > > > I think we need to clarify what this proposed feature does, exactly. > > James' AppConfig proposal (with the parallel to unmanaged models) sounds > > to me like a "migrations should ignore this app entirely" flag (which > > would impact both `makemigrations` and `migrate`). Such a flag wouldn't > > be useful for any reusable app that has models (and thus migrations). > > I'm not opposed to this, though (much like unmanaged models themselves) > > I don't think it'll be frequently used. It's basically a way to opt out > > of migrations entirely. > > > > Agreed. > > > It seems like what Marcin wants is more of a "don't ever create new > > migrations for this app, but go ahead and use its existing ones > > normally" flag (thus something that affects only `makemigrations`, not > > `migrate`). > > That's what I'd want too. > > > Personally I don't really see much use case for this feature > > except as a workaround for reusable apps that generate spurious new > > migrations based on settings changes > > I've also seen it with apps that use "EmailField" without specifying > explicit > length (which I'd expect to be the common way to use it...) > > > (e.g. the dynamic-choices case). > > Normally an app shouldn't ever generate a new migration from > > `makemigrations` unless you've modified its models code. So I'd be more > > in favor of addressing the actual problems causing spurious new > migrations. > > > > That's "the best getting in the way of the good". Solving the problem at > the > source is best, and making reusable apps more robust in this sense is a > great > cause, but it shouldn't stop us from putting workarounds in the hands of > users. > > > Also, FWIW, the latter is already fairly easy to implement yourself by > > overriding `makemigrations` in your project and giving it a default list > > of app names if none are provided. > > > > I don't think that's a good answer for users (and it can't even be > implemented > as a reusable app without adding a setting). > > Shai. > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALMtK1HfFTEEmm7m1UDVhcTX2xiGfjRpN105yqq0h6FY2zHXpQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
