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

-- 
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/55AD17FB.8000302%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to