Consider to replace Compass against libsass

[jrief]

This would have many advantages:

• Faster compilation times, some say up to 11x faster.
• No need for Ruby gems and that stuff, everything is installable through pip.
• Files ending in .scss are referenced directly in the templates, rather than having to refer an autogenerated css-file.
• Only one file has to be revisioned in git: the scss-file. The css file is generated on the fly and kept in the compressors cache.
• No daemon, watching a subtree of the filesystem, must be started. The library django-compress and libsass will handle everything for us.

For more information refer to this post: https://groups.google.com/forum/#!topic/django-cms/KO7K1iMIjmo

[yakky]

Compass is just used on the CMS developer side to compile core styles, and it shouldn't dictate any specific tool for developing websites with django CMS
Or am I missing something?

[stefanfoulis]

The setup is very cool and makes the static pipeline much simpler. The problem I see with incorporating this into django-cms itself, is that we'd force the django-compress and libsass dependencies and the additional configuration needed on everyone using django-cms.
But it looks to me the setup would still allow other solutions to be used for other assets in the project (e.g LESS, plain css, ...). correct?

Pros:

• easier for django-cms core developers to manage assets
• probably easier to selectively override cms styles in your own projects, should you need to
• much easier asset management for django-cms developers if you buy into this opinionated SASS setup

Cons:

• more external dependencies (libsass is a c library, which might be hard to install in some environments)
• more complex project configuration

[jrief]

@yakky
If you'd use djangoCMS as a pure CMS, without adding customized Views, than I'd agree. But this audience assumingly is using Wordpress anyway. The big advantage of djangoCMS is its ubiquitous
way to integrate with existing django applications. But for these you need (or at least are strongly encouraged) to use a CSS preprocessor anyway. For this audience libsass is a huge benefit. And if you prefer less or stylus, well than go ahead. However, one of the nice thing with SASS is, that you then can even allow an external developer to parametrize elements from the CMS. Say someone wants a pink admin area, then just change that variable.

@stefanfoulis

Cons:
more external dependencies (libsass is a c library, which might be hard to install in some environments) more complex project configuration

so is PIL, psycopg2, lxml. Without a C compiler you won't be able to install a virtual environment for djangoCMS anyway. Therefore IMHO that's a very week con.

more complex project configuration

would you say, that a separate config.rb is less complicate than a few extra options in our well known settings.py? For me, with libsass its even easier to configure than it was with compass.

Can we vote about this?

[yakky]

@jrief I'm definitely not voting against libsass at all! Your article is very interesting and I'm looking forward to implement it.
What I was thinking about is if requiring libsass for a django CMS website it's a good thing or not, given that as of now django CMS does not dictate in any way the CSS preprocessor or asset management to use.

[jrief]

@yakky this is a valid argument.
However, my personal impression is, that SASS gains a lot of momentum over less and stylus now. Nobody is forced to use SASS together with djangoCMS but it is a good default. One thing, which in the future could really make a lot of sense, is to let agencies or even backend-users style the CMS-admin part using a few SASS variables.

[jrief]

On the long term we should even consider to remove all third party libraries from the git repo and replace them by node_modules and/or bower_componets controlled by a tool such as shrinkwrap.

I just came across this wonderful statement:
“An important principle of software version control is that you don't check in files derived directly from other files by a simple transformation.”
(source http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/)

[jrief]

Since there is some opposition to require django-compressor and libsass on each client installation, I'd like to make this proposal:

django-sekizai is a mandatory requirement for django-cms, so we can add a postprocessor in
{% render_block "css" postprocessor "compressor.yet.to.be.written" %}.

This new compressor will do the following:
If django-compressor and libsass are installed, proceed as described above. This allows users of libsass to compile their customized SCSS files from their project and concatenate them together with compiled SCSS files from django-cms.

Otherwise, if django-compressor or libsass are not available, map the referred ...scss file to a ...css file and deliver that one. Now of course, these CSS files must be pre-compiled and shipped with django-cms.

I would add this compilation step into setup.py, but without requiring Ruby or compass – its all done in plain Python. This means that whenever django-cms is built, those SCSS files are converted to CSS files. It also means that we won't check in files derived from other files. In my opinion, it is bad practice to add files to the repository, derived directly from other files by a simple transformation. This currently used practice, then finally can be eliminated.

I don't believe that developers, working directly against the CMS source tree, would have a problem to add libsass to their development requirements.

@yakky @stefanfoulis : If you think this is a feasible solution, I'll add that feature.

[yakky]

@jrief That would be an awesome solution!

[evildmp]

@FinalAngel Angelo, would you mind giving this a) a quick look and b) your opinion?

[DivioTravisCI]

@jrief Love it. So developers just installing django-cms from pypi will not
be required to install libsass (they get the pre-compiled css that is
generated when doing "python setup.py sdist"). But if you choose to use
libsass you can easily override certain parts of the django-cms css without
copying everything.
Great :-)

On Tue, Dec 9, 2014 at 5:25 PM, Daniele Procida notifications@github.com
wrote:

@FinalAngel https://github.com/FinalAngel Angelo, would you mind giving
this a) a quick look and b) your opinion?

Reply to this email directly or view it on GitHub
#3600 (comment).

Divio AG
Stefan Foulis
Senior Software Engineer

stefan.foulis@divio.ch

http://www.divio.ch/
http://github.com/stefanfoulis/

[jrief]

I already started with implementing this.

The good news is, that django-compressor allows pregeneration of CSS files though ./manage.py compress, so that on productive servers only django-compressor is required but not libsass.
The bad news is, that I was able to precompress the files, but unable to access them. My question about this issue unfortunately has not been answered yet.

So unless we postpone precompression, I'll have to wait until I get an answer for the above question.
One reason why precompression might not make much sense anyway is, that with libsass in theory we could allow each client of djangoCMS to configure it's personal admin style.

[FinalAngel]

We have the goal also internally to move over to libsass, however there are other dependencies to consider such as autoprefixer which have to work as well (in order to get rid of compass)

Regarding the libsass dependency, I'm with @yakky and @stefanfoulis on the additional requirements. We should rather make it easier to configure the cms than harder. It might also draw developers away if they are using less and see that the cms supports natively only sass.

Though I'm pro for dropping compass at some point. (would target this for 3.2 though)

[jrief]

@ojii
since you are the maintainer of django-sekizai, I'd like to ask you if you can have a look at integrating offline compression in Sekizai with django-compressor.
django-compressor has a management command to offline compress all referred css files, but this requires to place JS/CSS files inside a {% compress "..." %} template tag.
Since Sekizai uses its own {% renderblock ... %} templatetags, this is incompatible.
I had a look at the code, but you need deep knowledge of Sekizai and/or Compressor to fix this.

Therefore in order to implement this useful feature we have 3 options:

1. Drop the requirement for offline compression.
2. Fix this problem in Sekizai/Compressor.
3. Implement an alternative offline compression directly into Sekizai.

Please see django-compressor/django-compressor#351: Update docs to note that django-sekizai doesn't work with offline compression.

If 2. and 3. are impossible to solve, would 1. be an option?

[ojii]

since you are the maintainer of django-sekizai, I'd like to ask you if you can have a look at integrating offline compression in Sekizai with django-compressor.

I had a look at this a while back and the problem is that offline compression isn't compatible with sekizai, because with sekizai the whole idea is that you don't know in advance (in the case of django CMS at least) what assets will end up on a page. I guess there could be a way to compress each individual addtoblock call, which kind of defeats the idea of compressing/combining the assets. As with the postprocessor, I'd prefer this not being part of sekizai but either compressor or a new 3rd party app. Instead of just scanning for compress tags, this would then also scan addtoblock tags.

[jrief]

@ojii so, what you say is, that there will not be any solution in the near future which can use django-compress with Sekizai.

Ok, then we have to reconsider option 1 again, or drop that feature completely.
Since that would be rather sad, I would like to emphasize again, that adding libsass to the dependency stack does not enforce anyone to use SASS instead of his preferred preprocessor such as LESS or STYLUS. They can coexists very well side by side. Its even beneficial, because then the users of, say LESS, simply have to add their preprocessor to the list of COMPRESS_PRECOMPILERS.

[ojii]

@ojii so, what you say is, that there will not be any solution in the near future which can use django-compress with Sekizai.

Just for clarification, you can use django-sekizai with django-compressor, the amazing folks over at compressor made that happen. What is not possible at the moment is offline compression because of technical (how compressor looks for files to offline compress) and logical (way of how sekizai is intended to be used) reasons.

I know offline compression + sekizai is an important topic to people, but I have no answer for it at the moment. I'd be very interested in actual solutions (proposed or implemented) for this, but let's discuss this over on the django-sekizai tracker (if you happen to have a solution).

[jrief]

We now have a solution to solve this:
django-cms/django-sekizai#41

[jrief]

django-sekizai-processors

I just released a package to do the *.scss to *.css conversion using Sekizai's templatetag addtoblock.
Additionally all referred *.scss files can be compiled offline, using ./manage.py compilescss and hence deployed onto production systems without the need of libsass.

Additionally it adds a sourcemap to each compiled file, so that when using element inspection on modern browsers, the source file is referred instead of the compiled css file.

For details, please see here: https://pypi.python.org/pypi/django-sekizai-processors/0.1.0

This means, we now could start to migrate django-cms to use libasss exclusively, instead of Ruby SASS

[yakky]

\O/ great job @jrief !

[FinalAngel]

So after digging into deeper:

I will start now on a libsass branch where I migrate accordingly. Though using django-libsass is the wrong package for the job. In case of the CMS, we compile it on release and package it within the CMS.

Backing the django stack on the libsass compilation is the wrong move, we need to include a node / gulp (or Grunt) kinda way to compile, minify, concatenate, lint and optimise the generated output. Frontend developers are far more comfortable working in that environment. Additionally we need autoprefixer support to take care of the lack of mixins on the libsass front, there is not yet a solution for django there.

Also considering all the other advantages which we get through node such as linting and at some point testing. I'll reference my efforts to this issue.

[yakky]

Agree. Decoupling the CMS deployment from any specific way to generate and serve assets it's the only viable option, while still having a more integrated option is a very welcome addition

[FinalAngel]

Checkout https://github.com/FinalAngel/django-cms/pull/6/

[jrief]

May I remind to evaluate this package: https://github.com/jrief/django-sass-processor
@yakky had a concern to not install libsass on the server, therefore I wrote this package. It is able to combine the compilation with compression and the concatenation step.
During development I serve all CSS files with a sourcemap making SCSS debugging a piece of cake and during production I deliver only one CSS file, which has been pre-compiled on the development host.

[FinalAngel]

@jrief though it has some downsides:

• no autoprefixer support (which is a must, libsass without it is half the cake)
• no live-reload capabilities (which can easily be handled over the npm ecosystem)
• very good on a project level, but not for django-cms (as we ship the cms with precompiled css anyways)

things I'm not sure of:

• speed might be affected as you add additional static finders and tags
• whats the gain over django-libsass which seems for me to be simpler to understand

[jrief]

@FinalAngel

• what do you mean by autoprefixer support? BTW, I currently use this library together with the SASS- port from Bootstrap installed via npm into a local node_modules.
• live-reload could be added directly into Django using websockets. I made this proposal to @intellectronica in another context, but got no answer until now. The benefit would be, that you then don't need any nodejs process running side by side and that you could also use it on template and code changes. Lets discuss about that.
• Speed would only be problem during development. But I didn't measure any difference.
• With django-libsass you can't precompile css and you don't get any sourcemaps.

[FinalAngel]

@jrief just to answer your points

• autoprefixer: https://github.com/postcss/autoprefixer
• live-reload: well we want it sooner than later and there are plenty options for node
• speed: alright, still cautious about if it won't affect the live env as well
• django-libsass: sourcemaps can be generated through LIBSASS_SOURCE_COMMENTS

anyhow, my proposal goes towards the node integration in https://github.com/FinalAngel/django-cms/pull/6. Using the right tool for the right job ;)

[driesdesmet]

However supportive I would be if you could use a python only solution, after much tinkering with different methods (sekzai/django-compressor, django-bower and the like) I'm glad @FinalAngels' branch proposes the gulp
route. The python ecosystem is just not at the same level at the moment for front-end stuff. That doesn't put out my hope for improvement, but it's the right path for noe I think.

[jrief]

@driesdesmet https://github.com/jrief/django-sass-processor is a pure Python approach. That's the reason I wrote it. The second reason was, that I dislike having to run a daemon, watching some directories and then acting.
I agree with @FinalAngel that autoprefixer and live-reload are a cool features. While live-reload can be integrated into Django quite easily, autoprefixer is more tricky.

[FinalAngel]

done :)