Evaluate inclusion of django-pipeline instead of django-compressor

[pmclanahan]

Django-pipeline is excellent, and seems like much more the way-to-go for Mozilla web projects. It supports all the things, even JS templates, and is well maintained.

http://django-pipeline.readthedocs.org/

Discuss.

[pmclanahan]

We should also consider WhiteNoise. This is the stack Scrumbugs is currently using and it's working wonderfully.

[peterbe]

So I implemented django-pipeline on the playdoh example project. It worked like a charm!

The concern I had was that the output_filename would be irrelevant when the filename should be hashed. Turns out that it's just a "template". If you write 'output_filename': 'foo.css' it later becomes foo.31196a9ec950.css when you have run collectstatic AND your settings.DEBUG==False.

Considering that @jezdez is for the change, I'm perfectly happy that we change playdoh-lib and funfactory to default to django-pipeline instead. That might screw some people over who use django-compressor and do a upgrade of their playdoh-lib so we should try to smoothen that transition.

[peterbe]

Note-to-self: If you forcibly set PIPELINE_ENABLED=True, concatenation and minification works but you don't get hashed output files. Only setting DEBUG=False does that.

[peterbe]

Here's the branch:
https://github.com/peterbe/playdoh/tree/django-pipeline
What I did was that I installed futures and django-pipeline myself but if we go ahead with this, those two packages should live in playdoh-lib instead.

[pmclanahan]

It also matters a great deal your STATICFILES_STORAGE setting (of course). When combining WhiteNoise and pipeline you need to create your own class, but it's very simple and playdoh could provide it easily:

https://github.com/mozilla/scrumbugz/blob/master/scrum/storage.py

[peterbe]

I have no objections to WhiteNoise but I feel that's a separate issue altogether. Also, it hinges on there being a CDN you can use. All of the playdohesque projects I work on don't have a CDN.