Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A first stab at aligning migrations with recent versions of Django.
Existing migrations are moved to south_migrations. This means South users will need to be >= 1.0.0 which looks for this directory, or they will have to add to their settings.py:
I have not extensively tested this on existing projects, but it should be enough to get the conversation started.
Also a great blog post here on supporting new Django migrations in third-party apps: http://treyhunner.com/2014/03/migrating-to-django-1-dot-7/
Note: if you need this right now (for instance if Django is blowing up because you have a custom AUTH_USER model that needs to migrate before oauth2_provider, e.g. if you're seeing things like
django.db.utils.ProgrammingError: relation "myapp_user" does not exist
when you run your tests), you can replicate the new migrations folder from my fork into your app as something likemyapp/oauth2_provider_migrations/
and then add to your settings.py:Assuming you've been using oauth2_provider for a while, you will need to fake the migration on your regular db so it doesn't complain about the table already being there in the future: