Skip to content
This repository has been archived by the owner on Jan 8, 2019. It is now read-only.

Update playdoh documentation on django-compressor vs jingo-minify #148

Open
JordanReiter opened this issue Feb 27, 2013 · 6 comments
Open

Comments

@JordanReiter
Copy link

"Current" documentation still states that jingo-minify is being used rather than django-compressor to handle static files.

@Osmose
Copy link
Contributor

Osmose commented Feb 27, 2013

Hmmm, is there anyone using playdoh who actually uses django-compressor? I ran into so many issues getting it to work that I gave up and went back to jingo-minify, and I know at least one other site did the same thing.

IMO if enough people are rejecting it we should just move back to jingo-minify, it works great with staticfiles now.

EDIT: Not to sound ungrateful to peterbe, whose lovely work on django-jingo-offline-compressor solved a lot of the bigger issues I faced.

@willkg
Copy link
Member

willkg commented Feb 27, 2013

Kitsune uses jingo-minify for mostly historical reasons. Fjord (the new input) uses jingo-minify because we also had a lot of problems with django-compressor and it was easier to fix issues with jingo-minify (it didn't support django 1.4 conventions at the time) and go with that.

There are things about django-compressor I really like, but I hate the "let's do all the things at request time!" idea. @peterbe was working on fixing that, but I can't remember if we tried django-compressor before or after that work. Maybe it's worth looking at again.

@JordanReiter
Copy link
Author

Okay, so I guess it was jingo-minify to django-compressor then back to jingo-minify? That explains my confusion.

@peterbe
Copy link
Contributor

peterbe commented Feb 27, 2013

django-jingo-offline-compressor is now in staging servers for socorro but as you might have noticed it's still in my personal repo and not been put in playdoh-lib.

For new projects, I'm planning to use django-jingo-offline-compressor personally but that's because I'm close the source and would stand a good chance to debug problems.

If others (like, the majority) feel more comfortable with jingo-minify then perhaps we should switch playdoh back to that.

Remember, the main reasons we switched to django-compressor were:

  1. works with staticfiles
  2. one less in-house moving part to worry about
  3. makes working with .less easy

@Osmose
Copy link
Contributor

Osmose commented Feb 27, 2013

As of now, 1 isn't relevant now that jingo-minify supports staticfiles, 2 is still a very valid concern, and 3 I'm not sure about. What are the issues with jingo-minify and LESS?

@gerardo
Copy link

gerardo commented Mar 28, 2013

Has anybody considered using django-pipeline? It's closer to jingo-minify than django-compressor in the way of declaring assets. It also supports CoffeeScript and Jinja.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants