Re: Why Django is making migrations for external apps?

[Loïc Bistuer]

+1!

Loïc

> On Jul 17, 2015, at 23:30, Andrew Godwin <and...@aeracode.org> wrote:
>
>
>
> On Fri, Jul 17, 2015 at 11:19 AM, James Bennett <ubern...@gmail.com> wrote:
> One option for declaring an app "unmanaged" could be via AppConfig. That's fairly clean, mirrors the way you can already set a model as unmanaged in its Meta declaration, and allows for the end user of the app to override by supplying an AppConfig which will generate migrations (should they, for some use-case reason, want that).
>
> Now this I like.
>
> Andrew
>
> --
> 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 post to this group, send email to django-d...@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/CAFwN1uq8bhij2WABvrRW7QPuMcCwVg6d7qKiuMREh2Udb8vNpA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Florian Apolloner]

On Friday, July 17, 2015 at 6:31:20 PM UTC+2, Andrew Godwin wrote:

On Fri, Jul 17, 2015 at 11:19 AM, James Bennett <ubern...@gmail.com> wrote:

One option for declaring an app "unmanaged" could be via AppConfig. That's fairly clean, mirrors the way you can already set a model as unmanaged in its Meta declaration, and allows for the end user of the app to override by supplying an AppConfig which will generate migrations (should they, for some use-case reason, want that).

Now this I like.

Ditto. At some point we might wanna evaluate if we have more settings where this could come handy (MIGRATION_MODULES seems like a perfect fit too).

[Marcin Nowak]

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". 

BR

Marcin

On 17 July 2015 at 18:30, Andrew Godwin <and...@aeracode.org> wrote:

On Fri, Jul 17, 2015 at 11:19 AM, James Bennett <ubern...@gmail.com> wrote:

One option for declaring an app "unmanaged" could be via AppConfig. That's fairly clean, mirrors the way you can already set a model as unmanaged in its Meta declaration, and allows for the end user of the app to override by supplying an AppConfig which will generate migrations (should they, for some use-case reason, want that).

Now this I like.

Andrew 

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/WgFacUFvgfs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

[Carl Meyer]

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.

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`). 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 (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.

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.

Carl

[Shai Berger]

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.

[Anssi Kääriäinen]

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

[Carl Meyer]

Hi Shai,

On 07/19/2015 01:52 AM, Shai Berger wrote:
[snip]

>> 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...)

Why would this cause a spurious new migration?

>> (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.

Yes, you're right.

I think Anssi's three-valued `migrations_mode` AppConfig setting would work.

>> 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).

I actually think it's a good technique for users to be familiar with, as
it's a powerful way to change the behavior of any management command (or
add new shortcuts as desired), and it only takes a few lines of code to
do so.

But you're right that it's not very composable or reusable; it's a
project-level technique.

Carl

[Carl Meyer]

On 07/19/2015 06:14 AM, Anssi Kääriäinen wrote:
> 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.

I think this is a good proposal. It should be an AppConfig setting, so
in case of need it is possible for an end user to override the author's
choice.

I'm not sure about adding this to models; there it would duplicate the
existing `managed` meta setting.

Carl

[Shai Berger]

On Monday 20 July 2015 18:47:07 Carl Meyer wrote:
> >
> >> 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...)
>
> Why would this cause a spurious new migration?
>

It's arguably a bug in the reusable app. The app supported Django 1.7. Then
they wanted to support Django 1.8, and its change of the default length of
EmailField. So they added a migration that enlarges the field from 75 to 254.
This actually makes a lot of sense for anybody upgrading from 1.7 to 1.8.
However, if you use it with 1.7, makemigrations wants to add a migration to
pull it back down to 75.

I'm not sure what the reusable app was supposed to do here. They could drop
support for 1.7 (or limit it to the older branch). They could make a separate
release for each of the versions, differentiated only by the presence of the
migration file. They could specify explicitly one of the lengthes, which would
make their EmailFields incompatible with other default EmailFields (if there
is ever reason to copy values from a field in one model to another, and these
things do happen). None of these options are without prices. Even detecting
the Django version in the migration and picking the length accordingly is
problematic (if the migration is run before the Django upgrade, it will miss
its purpose).

The bug in the app is still open:
https://github.com/omab/python-social-auth/issues/622

Shai.

[Carl Meyer]

I see, thanks for the explanation. ISTM that the best available solution
for this situation is to specify the length of the field explicitly to
254. Yes, this means that a Django 1.7 user copying an email address
from the social-auth email field to some other default-length email
field might have to figure out what to do with emails longer than 75
characters, but a) that's not likely a common case, and b) such a user
has the migration system available to just lengthen their own email
field with an explicitly-specified length, too.

Carl

[Markus Holtermann]

The recommended way is to specify the length explicitly and use the
lowest Django version to generate migrations you want to support.

/Markus

>--

>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 post to this group, send email to django-d...@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/55AD3658.5090902%40oddbird.net.

>For more options, visit https://groups.google.com/d/optout.

--