> 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/b2539e2b-a3c5-4b83-8433-ea921e19a16e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
