Is it possible that we switch from cheetah to a lighter weight template engine?.

[Frankie Onuonga]

Switch is suggested as cheetah pulls in too many dependencies.

I would like to suggest something smaller to ensure our package is lighter.

Related bugs:
 bug 1247132: Python 3 support and dropping cheetah

[Joshua Harlow (harlowja)]

Ah, I tried this one a while ago by using tempita. The problem I think will be the issue of legacy templates that people have built & are actively using. Changing from cheetah (which might be good anyway) will require a version number bump I think. Do you know of a templating engine that uses cheetah like syntax, but is simpler/smaller? Tempita doesn't seem to fit the bill (the syntax is very different).

[Frankie Onuonga (frankieonuonga)]

Well I can look into it and I am sure we will get something up and running.You are right it will require a version bump.
This is a long term view.
I think it might be important for us in the future.

Smaller footprint is good I think.

Kindly give me 48 hours to look into the issue.

[Scott Moser (smoser)]

Yeah, backwards compat is the thing I'm worried about.
I'm probably willing to allow us to do best-effort backwards compat.

Ie, if we can handle the basic use of cheetah that we have in existing templates and give users a way to do more powerful things in another templating language.

I'd suggest that we require new templates to "declare" they're of the new template engine format.
Ie, perhaps the templates for the new template engine would start with '#newtemplate-engine'.
templates read that had no (known) '#<template>-engine' at the start of the file would be read with our backwards-compat cheetah. And if the user needed full cheetah support, then they'd have to declare '#<cheetah>-engine'. In that case we'd try to dynamically load cheetah, to do away with the dependency and only use it where really necessary.

Just fyi, My primary interest in this is really python3, not "have less dependencies".

[Joshua Harlow (harlowja)]

Mako might be a good choice, it looks somewhat similar to cheetah.

http://docs.makotemplates.org/en/latest/usage.html#basic-usage

[Frankie Onuonga (frankieonuonga)]

My thinking is we should have a look at what is here, https://wiki.python.org/moin/Templating and look at what will work for us in the future:

I am sorry I have been off for sometime. I have been busy at work.

In response to @Scott I respect your opinion but can i argue that focus to python3 might not be as urgent for a couple of releases.

I am only suggesting so. I do not mean to offend you in any way.

[Frankie Onuonga (frankieonuonga)]

Hi, I take back what I said. I have looked around and @harlowja is right. Mako seems to be a good option.

[Frankie Onuonga (frankieonuonga)]

Thanks Scott. I am excited to see this. Is there any way I can be off assistance with these changes. In python 3, is there any template engine we are going with by default.? Thank you.

[Bohuslav "Slavek" Kabrda (bkabrda)]

Hi, I'd also like to be of assistance here. Scott, reading this bug and bug 1247132, I'm not sure where I could help right now - are you suggesting that we need to support cheetah-compatbile syntax in python3 port? Or are you suggesting that we support different template syntax as a default for the python3 port?
The first option seems unlikely to happen, since cheetah upstream is dead and I don't know any templating engine that would be fully compatible with cheetah. The second option would be, in my eyes, very confusing, since I'd expect the same beheviour regardless of Python version I run cloud-init with.
What I'm trying to say is, we should decide to switch to another templating engine (e.g. mako) and stick with it.
Or we could do a compromise and support both mako and cheetah for Python 2 and only mako for Python 3 (and differentiate between them e.g. based on file extension or sth. like that).

Would that be acceptable?
Thanks!

[frankie onuonga (frankie-onuonga-deactivatedaccount-deactivatedaccount-deactivatedaccount)]

Hi,
I was hoping to move away from that template engine to something light and
as a result faster.

kind regards

On Wed, Jul 16, 2014 at 12:09 PM, Bohuslav "Slavek" Kabrda <
<email address hidden>> wrote:

> Hi, I'd also like to be of assistance here. Scott, reading this bug and
> bug 1247132, I'm not sure where I could help right now - are you suggesting
> that we need to support cheetah-compatbile syntax in python3 port? Or are
> you suggesting that we support different template syntax as a default for
> the python3 port?
> The first option seems unlikely to happen, since cheetah upstream is dead
> and I don't know any templating engine that would be fully compatible with
> cheetah. The second option would be, in my eyes, very confusing, since I'd
> expect the same beheviour regardless of Python version I run cloud-init
> with.
> What I'm trying to say is, we should decide to switch to another
> templating engine (e.g. mako) and stick with it.
> Or we could do a compromise and support both mako and cheetah for Python 2
> and only mako for Python 3 (and differentiate between them e.g. based on
> file extension or sth. like that).
>
> Would that be acceptable?
> Thanks!
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1219223
>
> Title:
> Is it possible that we switch from cheetah to a lighter weight
> template engine?.
>
> Status in Init scripts for use on cloud images:
> Triaged
>
> Bug description:
> Switch is suggested as cheetah pulls in too many dependencies.
>
> I would like to suggest something smaller to ensure our package is
> lighter.
>
> Related bugs:
> bug 1247132: Python 3 support and dropping cheetah
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cloud-init/+bug/1219223/+subscriptions
>

--
Skype: Frankie.Onuonga
twitter: Frankieonuonga
irc #freenode: Frankieonuonga

[Scott Moser (smoser)]

frankie,
  see what Josh suggested at https://code.launchpad.net/~harlowja/cloud-init/changeable-templates/+merge/208994

[Scott Moser (smoser)]

fixed in 0.7.6

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/2390