-
Notifications
You must be signed in to change notification settings - Fork 276
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Django 1.9 compatibility #345
Conversation
maybe the developer wants to test his cache configuration locally, or maybe he has to test different types of caches, we just don't know
# DEFAULT_CACHE_ALIAS doesn't exist in Django<=1.2 | ||
try: | ||
from django.core.cache import DEFAULT_CACHE_ALIAS as default_cache_alias | ||
from django.core.cache import DEFAULT_CACHE_ALIAS | ||
default_cache_alias = DEFAULT_CACHE_ALIAS or 'default' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DEFAULT_CACHE_ALIAS is not a setting in Django. It is a constant from when it was introduced (in django 1.3) to nowadays. It was always 'default'
and probably it will be allays 'default'
. If the value changes for some reason probably the django cache framework will know what to do and we do not need to fallback to something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @vstoykov for the explanation, very clear. I will restore the behavior then
The only place where tests are failing is for Django 1.2 @matthewwithanm need to tell us if he still want to support django 1.2 or we can drop the support. Also this PR changes the way how imagekit cache backend is configured. Untill django 1.9 whith the |
Totally @vstoykov, we are on the same page. Me too I prefer the explicit caches rather than the implicit one. I will add some changes to the documentation. Btw, @matthewwithanm the previous LTS was Django 1.4, the new LTS is Django 1.8, which means it would probably don't hurt to drop support for Django<1.4. And it would simplify the project code for sure. I'm motivated to make those changes happen if you give your green light @matthewwithanm :) Cheers |
supported python versions can be found at https://docs.djangoproject.com/en/1.9/releases/1.9/
Btw, I've added Django 1.9 to the test envs, and improved the travis conf to split the test builds. |
Please merge this :) |
@matthewwithanm I merged this PR and closed other PRs and issues related to this. What you think about @bryanveloso to release new version in order users wanted to upgrade to Django 1.9 to do it? |
DO IT 👍 |
Bam! Thanks guys! |
3.3 is live. 💥 |
Nice 😎 |
As discussed in the #321, we can probably just use the
caches
and not django private method.This pull request can be opened to bring Django 1.9 compatibility, as we highly need it I am ready to fix warnings and issues nearly daily basis.
Cheers