Thank you for your patches and ideas of how to solve this feature, Emmanuelle.
However, I strongly agree with Andrew that, if we allow this -- I'm on Tim's side here, it feels odd encouriging something that's not considered to be used for that purpose: `contribute_to_class` -- the solution should be in the MigrationLoader. But as Andrew already said, you *will have* problems when you have your own migrations and a third party app adds a new one. Suddenly there are two leafs which is an invalid state. You will have to run `manage.py makemigrations --merge theapp` to fix this. The only sane solution I see right now is allowing MIGRATION_MODULES to take a string or list as values for each app. At which point Django needs to know where to place the merge-migration. I'd go with the first item in the list. However, I still don't like the idea either and would and will continue to recommend to copy the migration files as proposed by Tim earlier. /Markus On Thursday, September 3, 2015 at 4:09:46 AM UTC+10, Emmanuelle Delescolle wrote: > > > My main concern is not with the complexity of your proposed patch but with >> committing to supporting a new API that solves a problem that can already >> be solved a different way (albeit maybe less elegantly). Anyway, I don't >> want to speak definitely about the issue, but it seems like if we keep >> thinking about the problems maybe we could come up with a more elegant >> solution that doesn't need to marked as "dangerous". >> > > Well, my first idea was to have a re-usable app deal with this case, this > is actually how I've been handling it thus far. The problem with my current > "reusable" app is that it's not very re-usable since there is no easy way > of doing hat the path does in a re-usable app without copy-pasting most of > the Django file because the migrated app is "hard-coded" to self.app_label > and I now have 3 versions of that code depending on which version of Django > is being used. > > So here is what I'm thinking: here is another patch > https://github.com/django/django/compare/master...nanuxbe:migrate_other_app > which would allow for a third party tool to be written while not adding any > feature to Django. > Then Django doesn't have to actually support the feature (and therefore > isn't responsible for it) while still allowing it. > > What do you think? > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/86db9454-b9b6-404c-af62-c9d2fc1ff0ef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
