mads at kiilerich.com
Thu Apr 30 12:44:41 EDT 2015
On 04/27/2015 02:39 PM, Andrew Shadura wrote:
> 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
> 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?
More information about the kallithea-general