Look into django-jingo-offline-compressor. See if it solves our offline and development requirements. Generally that's: 1. must work in development environments and automatically update assets (django-compressor already did this, so it probably continues to be fine) 2. must allow us to compress and collect assets on an admin node through a command such that the results get pushed out to web-servers and they aren't dealing with compressing and collecting assets
Making this a 2 pointer. If it looks like it solves the problems that led us to jingo-minify, we should switch. If we bump into issues, we should help Peter sort them out.
Whiteboard: u=dev c=infrastructure p=2
What advantage does switching back to django-compressor & co. gain us? In particular, both requirements listed about are satisfied, to my knowledge. Is it a desire to stay cohesive with playdoh?
jingo-minify is EOLd plus it makes more sense to maintain which templates use which css/js files in the template rather than in the settings file (which you pointed out a while back).
Comment 3 is correct but I wouldn't put this on the critical path for phase-0 or even phase-1.
(In reply to James Socol [:jsocol, :james] from comment #4) > Comment 3 is correct but I wouldn't put this on the critical path for > phase-0 or even phase-1. I agree--that's why this doesn't block bug #780626. However, it'd probably help Peter if we did spend a little time with it soon which is one of the reasons I wrote it up.
I spent some time looking at this and decided we shouldn't go with django-compressor and fans. Paul and others have had good experiences with django-pipeline, so we should look at that instead. That's a different bug, though.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.