marrow.templating common templating/serialization API addition.

[amcgregor]

Howdy!

I've added marrow.templating support; one simple function, an entry point, and no additional dependencies.

Additionally, dump[s] commands now accept additional keyword arguments which are then passed to json.dumps, allowing you to control the serialization formatting.

[mitsuhiko]

I don't want to step into that particular direction with the library for the time being. Instead why not have a second library that implements the entrypoints for marrow if that is necessary? I still remember the last attempt of an unified templating language API and it was horrible, I don't want to be involved with that a second time.

[amcgregor]

Creating a whole separate package for what amounts to less than a dozen lines of glue is a fundamentally flawed idea.

I'd be curious to know what the previous attempt was; if it was buffet, I agree, it was terrible. Alacarte (now marrow.templating) takes a very minimal approach and already has support for json, pickle, marshal, yaml, and bencode serialization as well as a small army of full tempting engines.

The risk to you is zero; there are no additional dependencies within your own code. The benefit is currently small, benefiting the WebCore web framework and marrow.mailer e-mail delivery framework (formerly TurboMail), but I've also written the code for you. For further information on marrow.templating, see: https://github.com/marrow/marrow.templating

The other alternative, from my perspective, is to absorb this BSD licensed code into Marrow. I was planning on having a module like this anyway (utilizing a combination of MD5+SHA for additional hash lifetime security and zlib+hmac) for the Marrow cookie middleware.

Apologies if this all sounds rather hostile; creating a standard is difficult when developers aren't willing to click a single button (accept push request) to add support. Marrow.templating is currently in a chicken-egg scenario, with developers having been bitten by buffet not wanting to add support for proprietary, short-sighted, and/or selfish reasons.

[amcgregor]

As an additional note, minimal glue packages are one of the things I hated from Buffet; to use Cheetah I needed to install TurboCheetah, the naming of the glue package alone was enough to be off-putting. Marrow.templating is something that needs support from within the templating and serialization libraries themselves, and as you can see from the code (which took ~5 minutes to write), support is not difficult to add.

[Edited to add:] One additional point in favour of adding these commits: you want your package to be used by the widest range of people possible. How can adding additional API support (that has zero conceptual or actual load on your own code) be a bad thing?

[mitsuhiko]

I just really don't want to be the first to integrate it. I might at the very least check the API of marrow first and I would like to get someone else's opponion on this first.

[agronholm]

It's your decision of course, but at least hearing your 2 cents about the marrow.templating API would be very helpful.