collective / collective.recipe.template Goto Github PK

View Code? Open in Web Editor NEW

4.0 109.0 15.0 112 KB

Python 100.00%

collective.recipe.template's Introduction

Introduction

This recipe can be used to generate textfiles from a (text) template.

Contents

Features
- Genshi text templates
Why another template recipe?

A short example:

[buildout]
parts = message

[message]
recipe = collective.recipe.template
input = templates/message.in
output = ${buildout:parts-directory}/etc/message

mymessage = Hello, World!

In the template you can use the exact same variables as you can use in the buildout configuration. For example an input file can look like this:

My top level directory is ${buildout:directory}
Executables are stored in ${buildout:bin-directory}

As an extension to the buildout syntax you can reference variables from the current buildout part directly. For example:

My message is: ${mymessage}

Features

Starting with version 1.3, you can also specify a path to the output file and the path will be created if it does not exist.
Starting with version 1.5, you can use inline templates.
Starting with version 1.7, you can use genshi text templates.
Starting with version 1.9, you can use a URL to specify template input.
Starting with version 1.12, you can specify timeout as an option to configure urllib2 requests.
Starting with version 2.1, you can set input-encoding and output-encoding to specify the character encoding.

Genshi text templates

A short example:

[buildout]
parts = message

[message]
recipe = collective.recipe.template[genshi]:genshi
input = templates/message.in
output = ${buildout:parts-directory}/etc/message
some-option = value

mymessage = Hello, World!

In the template you can use the exact same variables as you can use in the buildout configuration, but instead of colons as the separator you either have to use attribute access, or for options with a dash dictionary syntax. The global buildout config is accessible through parts, the current part through options.

For example an input file can look like this:

My top level directory is ${parts.buildout.directory}
Executables are stored in ${parts.buildout['bin-directory']}
Accessing the current part: ${options['some-option']}

Why another template recipe?

Both iw.recipe.template and inquant.recipe.textfile claim to do the same thing. I have found them to be undocumented and too buggy for real world use, and neither are in a public repository where I could fix them. In addition this implementation leverages the buildout variable substitution code, making it a lot simpler.

collective.recipe.template's People

Contributors

Stargazers

Watchers

Forkers

seanchen mitchellrj enriquepablo jajadinimueter alecghica upcnet timonwong olimpiurob mstaniszczak dairiki baijum mvaled cynthiaborotpnv minddistrict fschulze

collective.recipe.template's Issues

Version 1.12 incompatible with zc.buildout 1.7.1

If I try to use the version 1.12 of the recipe to generate a simple file (no genshi involved) with zc.buildout 1.7.1 (latest in the 1.x series) then I get the following traceback:

An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
  File "/home/rafaelbc/trt3/trt3plone/python_buildout/eggs/zc.buildout-1.7.1-py2.7.egg/zc/buildout/buildout.py", line 1866, in main
    getattr(buildout, command)(args)
  File "/home/rafaelbc/trt3/trt3plone/python_buildout/eggs/zc.buildout-1.7.1-py2.7.egg/zc/buildout/buildout.py", line 509, in install
    [self[part]['recipe'] for part in install_parts]
  File "/home/rafaelbc/trt3/trt3plone/python_buildout/eggs/zc.buildout-1.7.1-py2.7.egg/zc/buildout/buildout.py", line 1104, in __getitem__
    options._initialize()
  File "/home/rafaelbc/trt3/trt3plone/python_buildout/eggs/zc.buildout-1.7.1-py2.7.egg/zc/buildout/buildout.py", line 1192, in _initialize
    self.recipe = recipe_class(buildout, name, self)
  File "/home/rafaelbc/trt3/trt3plone/python_buildout/eggs/collective.recipe.template-1.12-py2.7.egg/collective/recipe/template/__init__.py", line 35, in __init__
    self.overwrite = zc.buildout.buildout.bool_option(options, 'overwrite', True)
AttributeError: 'module' object has no attribute 'bool_option'

I think the solution is to restore compatibility with zc.buildout 1.x or increase the version number to 2.x and mention in the documentation this compatibility issue.

Note that zc.buildout 1.7.1 is what you get when you use Plone 4.3.6

parts using genshi templates need to be the first in buildouts

when using the genshi support in a buildout with multiple parts using collective.recipe.template one needs to take care that the first part is using the genshi extras.

eg the following buildout will fail with an import error::

  bin/buildout
  ...
    File ".buildout/eggs/collective.recipe.template-1.9-py2.7.egg/collective/recipe/template/__init__.py", line 54, in __init__
      self._execute()
    File ".buildout/eggs/collective.recipe.template-1.9-py2.7.egg/collective/recipe/template/genshitemplate.py", line 7, in _execute
      from genshi.template import Context, NewTextTemplate
  ImportError: No module named genshi.template

buildout.cfg:

parts = 
    template1
    template2

[template1]
recipe = collective.recipe.template
output = /tmp/template1.txt
input = inline:
    hello

[template2]
recipe = collective.recipe.template[genshi]:genshi
output = /tmp/template2.txt
input = inline:

    {% for item in range(1,10) %}\
        * item $item
    {% end %}

if you switched the order of the templates the buildout will run just fine

New release

What do you think, about creating new release (to pypi)? :)

problem with tests' starting

Hi,

I want to add simple functionality to collective.recipe.template - the ability to disable creating output file, in situation, when this output file already exists. But I have problem with tests. When I try execute tests (on vanilla, not modified package), I get error:

(test)mstaniszczak@mstaniszczak-desktop:~/Projects/crt$ ./bin/test 
Running zope.testrunner.layer.UnitTests tests:
  Set up zope.testrunner.layer.UnitTests in 0.000 seconds.


Failure in test /home/mstaniszczak/Projects/crt/collective/recipe/template/README.txt
Failed doctest test for README.txt
  File "/home/mstaniszczak/Projects/crt/collective/recipe/template/README.txt", line 0

----------------------------------------------------------------------
File "/home/mstaniszczak/Projects/crt/collective/recipe/template/README.txt", line 136, in README.txt
Failed example:
    print system(join('bin', 'buildout')),
Expected:
    Uninstalling template.
    Installing template.
Got:
    Uninstalling template.
    Installing template.
    Not found: /tmp/tmpIkEFznbuildouttests/zc.buildout/
    Not found: /tmp/tmpIkEFznbuildouttests/zc.buildout/

  Ran 2 tests with 1 failures, 0 errors and 0 skipped in 2.730 seconds.
Tearing down left over layers:
  Tear down zope.testrunner.layer.UnitTests in 0.000 seconds.

I'm not shure, what I do wrong? I use buildout attachet to collective.recipe.template. Can you help me? Thanks in advance.

Please make a new release

In 1b29d69 @regebro added Python 3 compatibility, please cut a new release.

variable substitution prepends a "=" sign

I have a very odd case that doesn't make sense. When my template is generated, any variables are inserted with a extra = in front of it.

So in the config and template below, the generated bin/npm script, on the third line ends up reading:

cd = /home/andre/dev/myapp/webapp/frontend/static

... when if fact it should be:

cd /home/andre/dev/myapp/webapp/frontend/static

buildout.cfg

[baseconfig]
webapp_dir= = ${buildout:directory}/webapp
resources_dir = ${buildout:directory}/resources
playbooks_dir = ${buildout:directory}/playbooks
npm_root = ${:resources_dir}/static/

[config]
<= baseconfig
npm_root = ${:webapp_dir}/frontend/static

[npm]
recipe = collective.recipe.template
input = templates/npm.sh.in
output = ${buildout:bin-directory}/npm
mode = 744

templates/npm.sh.in

#!/bin/bash

cd ${config:npm_root}

case "$1" in
    install)
        npm install
        ;;

    workbox)
        npm run workbox
        ;;

    copy-workbox)
        npm run copy-workbox
        ;;

    build-bower)
        npm run build-bower
        ;;

    build-sw)
        npm run build-sw
        ;;

    build-all)
        npm run build-all
        ;;

    *)
        echo $"Usage: $0 {install|workbox|copy-workbox|build-bower|build-sw|build-all}"
        exit 1
esac

urllib2 timeouts occurring - increase limit / make configurable?

I frequently have urllib2 timeouts occur because of the timeout of 1 second configured at https://github.com/collective/collective.recipe.template/blob/master/collective/recipe/template/__init__.py#L68 . I'm connected to a very fast net connection, but this timeout is too short when accessing resources across the web and is triggered about 90% of the time when pointing at URLs hosted on GitHub.

I propose both making this timeout configurable through a recipe option, and potentially increasing the default limit to something more forgiving, say 5 seconds. It would be nice to be in a situation where I don't need to remember to add a timeout = x option to the recipe to avoid this problem.

Thoughts? Any pressing reason why the timeout is so short? I can understand having a timeout since the default is to have none at all (and just wait forever).