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
support cloud completely #954
base: develop
Are you sure you want to change the base?
Conversation
e5531f0
to
3c7d4e3
Compare
3c7d4e3
to
509f345
Compare
Can you give any more detail what is broken/suboptimal right now and what this patch improves exactly? Also, since django 1.11 (which supports python 2.7) is supported until april 2020, i'd rather not break python 2.7 support now already. |
when the cache checks the modified time of a file, it calls os and checks against local file system. This makes this library impossible to use cloud storage as a backend storage completely. This PR tries to get that check by calling default_storage module. |
Yes, I will not merge this PR. Close this for now |
I'd keep this open, I can wait half a year :) |
we've dropped support for python 2.7, so this could be merged. however, i have tried to understand the code surrounding this and it seems like this only applies if offline compression is not enabled. So if you used a cloud storage for your static assets AND don't use offline compression, doesn't that imply compressor potentially downloads assets from your cloud storage, processes them, and uploads them again all while some client is requesting a page? why would you want to do that? While I'm not going to stop you, I'm trying to understand the use case this change is enabling :) for the protocol, i checked whether the other .opens in the codebase need this change as well. the only other relevant one was in CompilerFilter.input, and that one handles the output of calls to local executables, which i guess always output local files. |
use default-storage to store file instead of using FileSystemStorage
We will not support python 2.7