Templer and ZopeSkel
At the sprint following Plone Symposium East, I helped Cris Ewing write documentation for Templer, a Python code generation system that was derived from the older ZopeSkel application. I knew very little about Templer before the sprint, but the experience taught me that it is an incredibly useful tool for Python developers working with Plone, Django, Pyramid, or any other Python framework. Whether you are a freelancer or part of a larger web development organization, Templer can make you more productive.
Templer is a general-purpose system for generating code skeletons from pre-defined templates. End users provide information through an interactive interface, which is used to generate a skeleton of files and folders that make up a Python project. The projects that can be built with Templer today are:
- Python namespace and nested namespace packages
- Buildouts and recipes to extend the zc.buildout system
- Namespace and nested namespace packages for Zope
- Add-on packages for the Plone CMS
There are also commands (based on Python Paste) for adding features to Plone software projects that were created with Templer, such as browser views and Archetypes content types.
The functionality that Templer provides is very handy, but the thing that makes it a Python developer’s secret weapon is the fact that it can be extended and used to build applications focused on particular problems. ZopeSkel, which provides a suite of templates for generating Zope and Plone projects (buildouts, themes, add-ons, etc.), is one example of a Templer application. During the sprint, Ian Anderson began work on templer.django, a new Templer package to provide templates for Django projects. This package could form the basis of DjangoSkel, an application to quick-start Django projects. If you are in the business of creating Plone or Django websites, you can quick-start your own projects with a Templar based application. For example, MyPloneSkel could set up your production and development buildout configs just the way you like them, plus optional packages for Generic Setup policies, a Diazo or standard theme, and custom content types.
Thanks to everyone who has worked on ZopeSkel and Templer over the years to make such a useful suite of tools.
Comments are closed.
Jazkarta Blog 
Could we rename ZopeSkel to templer? Having different name for command is confusing, not to mention “Zope” being completely irrelevant 🙂
Domen,
I agree that the name Zope is largely irrelevant to templer. But the mistake here is in believing that ZopeSkel and templer are the same thing. They are not. Templer is envisioned as a framework for building templates, ZopeSkel is an individual application built using that framework.
ZopeSkel includes all the dependencies it requires in it’s own setup.py. When you `easy_install zopeskel` or `pip install zopeskel`, you get everything you need in one package, and the intention is for the totality that you get to be equivalent to the pre-3.0 version of ZopeSkel, when everything was one self-contained package.
Templer is not self-contained, it consists of a number of packages and advanced users can pick and choose among them. Many users (myself included) do not like including local commands since to do so is to end up with Paste, PasteScript and PasteDeploy in the src directory of your package every time you install it. With templer, you can get the basic templates to create archetypes-compatible or basic plone packages without needing to have local commands, but with ZopeSkel you get it all.
The idea here is that the system serves more than one master. There are newcomers who want to have a simple package they can install and use, ZopeSkel is that package. We also have experts who want to have a more tailored experience, templer is for them.
In the current version of ZopeSkel, when you install the package, you end up with a command-line tool called ‘zopeskel’, when you install templer, you get a command line tool that is called ‘templer’. In the next version, I have fixed it so that when you run each command, you get information that is tailored to the system you are using, so running `bin/zopeskel` refers only to zopeskel in help text and usage, and running `bin/templer` results in only seeing the name `templer` in documentation. There is some information out there which, if followed, leads to having both commands in place at once. This information is not correct. It is in no way required and certainly discouraged to install templer or ZopeSkel this way.
For the most canonical documentation on how to install and use either system, see the templer manual (http://templer-manual.readthedocs.org/en/latest/) at read-the-docs. The manual includes a section on `templer applications` and ZopeSkel is listed as the reference application built using templer (http://templer-manual.readthedocs.org/en/latest/applications/zopeskel.html)
If you, or anyone else, would like to learn more about the history, current activity and future of templer and ZopeSkel, vote for my talk for the plone conference (http://www.ploneconf.org/the-event/talks/conference-talks/zopeskel-the-past-present-and-future). I am also offering a one-hour tutorial talk aimed at teaching folks how best to use templer and ZopeSkel, and how to extend the system to fit their own needs (http://www.ploneconf.org/the-event/talks/conference-talks/jump-start-your-development-with-zopeskel)
I hope this answers your question, or at least gives you some food for thought. Thanks for your opinion, let’s keep talking it over.
It does! Given this information, ZopeSkel could be named templer.full or templer.star, then we can really start promoting it in other Python communities 🙂
It seems to me that ZopeSkel is a good name, since ZopeSkel is a Zope-specific application built on top of templer. And that what we need to promote templer to other Python communities is more apps built with it. templer.django and (eventually) DjangoSkel is a great start.