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.
