[PATCH PoC] Use webassets and lesscpy to precompile LESS into CSS and (optionally) minify JavaScript

[Mads Kiilerich]

On 04/27/2015 02:39 PM, Andrew Shadura wrote:
> Hello,
>
> On Mon, 27 Apr 2015 13:33:04 +0200
> Mads Kiilerich <mads at kiilerich.com> wrote:
>
>> It would be nice to get some introduction to what that means and why
>> we would do it - perhaps also some assessment of the pros and cons.
> Well, probably.
>
> The idea is that some of the "static" resources we serve might not be
> very well editable as they're served, so we might want to precompile
> them. An example would be minifying JavaScript or assembling a CSS out
> of smaller CSS files or by using a macrolanguage like LESS. And using
> LESS will help us manage the CSS which is already quite large;
> meanwhile, Bootstrap also uses LESS, so if/when we start using it too,
> we may use classes Bootstrap provides more easily.

Ok, we need a way to handle generated files (such as .css from .less and 
perhaps also js minimizers).

We should also have in mind that we currently (with some caveats) 
support serving static files (under kallithea/public, internally known 
as the static_files path) from the web server without hitting WSGI. 
Another nice-to-have would be the ability to serve all static files from 
another URL (cdn).

The simple solution to generated files is to have some command for 
generating the files and commit them. That is how we did with .mo files 
in the past. It might work at a smaller scale but isn't pretty. FWIW: 
I'm fine with handling less / css the same way until we experience a 
problem because of that. It seems quite common that projects commit and 
ship css generated from less.

Another solution is to just not commit these files (but include them in 
pip uploads) (and list them in .hgignore). People who need them from a 
checkout and during development will have to invoke the command to build 
the files. That is how .mo files are handled now. That works for that 
case where the files not are essential for development and where we 
rarely have a need for quick round trips.

So ... the purpose of this PoC is (as far as I understand from this and 
irc) to generate some of these kallithea/public/ files on startup.

I agree that it would be nice to have automatic rebuilding while 
developing. I do however not think it is something we would like to use 
for production. Servers should not have write access to their "source" 
tree and they should not even try to do it. We don't want every worker 
processes to check/build everything on startup. The dependency chain for 
the build process might also be so big that we don't want to put it on 
production front end servers. I would thus like this feature to be 
controlled by some kind of development flag - a bit like the 
static_files config option, enabled in development.ini.

That also means that we also should have some command (similar to 
setup.py compile_catalog?) for generating these files so we can include 
them in tar balls or admins can place them in the readonly location and 
upload to their CDN.

> WebAssets is a framework-agnostic module helping to arrange this sort
> of precompilation.

It can see this webassets library has a little build system and 
"filters" wrapping to tools generating files. It is probably fine for 
that. There might also be other fine tools for it, or our needs might be 
so simple that we don't even need any special build tool for it.

It seems to me like the main feature of webassets is its own fancy 
routing system. I would prefer to keep it simple and use the existing 
routing system. Or, perhaps this fancy routing system also hooks into 
the existing routing system and makes it possible to build in the fly? 
In that case I don't understand why it has to write to the 'static' 
public folder ... so I guess we don't use that part ...

How would you describe what we get from using webassets?

/Mads