diecutter

Templates as a service.

diecutter exposes an API where you manage templates as resources. The most common operation is to POST data to templates in order to retrieve generated files.

Files and directories are supported. Directories are rendered as archives.

Note

Diecutter is under active development: some (killer) features have not been implemented yet, or they are not mature. Check milestones and vision for details.

That said, features documented below actually work, so give it a try!

Example

GET raw content of a template:

$ curl -X GET http://diecutter.io/api/greetings.txt
{{ greetings|default('Hello') }} {{ name }}!

POST data to the template and retrieve generated content:

$ curl -X POST -d name=world http://diecutter.io/api/greetings.txt
Hello world!

Contents

Demo

Let’s try diecutter!

Online demo

There is an online server hosting diecutter’s demo:

In sourcecode

The demo/ directory in diecutter’s sourcecode [1] contains:

  • templates in templates/ folder.
  • some HTML-based client, specialized for the sphinx-docs template, as sphinx-docs.html file.
  • presets (input data) in presets/ folder.

Feel free to use it as a sandbox.

Note

the online demo uses templates from the source code!

Local demo server

System requirements:

  • Python [2] version 2.6 or 2.7, available as python command.

    Note

    You may use Virtualenv [3] to make sure the active python is the right one.

  • make and wget to use the provided Makefile.

Execute:

git clone git@github.com:novagile/diecutter.git
cd diecutter/
make develop
make serve

The last command runs diecutter service on localhost, port 8106. Check it at http://localhost:8106/

Tip

If you cannot execute the Makefile, read it and adapt the few commands it contains to your needs.

Examples

The following examples use the Local demo server. But you should be able to execute most of them on the online demo too.

The following examples are doctested [4], using Python’s WebTest [5] to run a diecutter server. Adapt the following setup to your needs:

>>> diecutter_url = diecutter_server.application_url

In the following examples, we use Python’s requests [6] as HTTP client.

>>> import requests
greetings.txt

Let’s work on file resource greetings.txt.

>>> greetings_url = diecutter_url + 'greetings.txt'

GET raw content of a template:

>>> response = requests.get(greetings_url)
>>> print response.content
{{ greetings|default('Hello') }} {{ name }}!

POST data to the template and retrieve generated content:

>>> response = requests.post(greetings_url, {'name': u'world'})
>>> print response.content
Hello world!

>>> response = requests.post(greetings_url, {'greetings': u'Greetings',
...                                          'name': u'professor Falken'})
>>> print response.content
Greetings professor Falken!

See Files for details about working with file resources.

django_admin.py startproject

Let’s work on directory resource +django_project+/.

>>> django_project_url = diecutter_url + '+django_project+'

It’s a directory. GET lists the templates it contains:

>>> response = requests.get(django_project_url)
>>> print response.content
+django_project+/manage.py
+django_project+/+django_project+/__init__.py
+django_project+/+django_project+/settings.py
+django_project+/+django_project+/urls.py
+django_project+/+django_project+/wsgi.py

Every template in a directory can be handled as a single file. But let’s focus on the directory feature...

POST returns an archive, with TAR.GZ format by default:

>>> django_project_url = diecutter_url + '+django_project+'

>>> from StringIO import StringIO
>>> import tarfile
>>> response = requests.post(django_project_url,
...                          {'django_project': u'demo'})
>>> response.headers['Content-Type']
'application/gzip; charset=UTF-8'
>>> archive = tarfile.open(fileobj=StringIO(response.content), mode='r|gz')
>>> print '\n'.join(archive.getnames())
demo/manage.py
demo/demo/__init__.py
demo/demo/settings.py
demo/demo/urls.py
demo/demo/wsgi.py
>>> archive.close()

Without trailing slash, directory name is used as a prefix for filenames. Let’s try the same requests with a trailing slash:

>>> django_project_url = diecutter_url + '+django_project+/'

>>> response = requests.get(django_project_url)
>>> print response.content
manage.py
+django_project+/__init__.py
+django_project+/settings.py
+django_project+/urls.py
+django_project+/wsgi.py

>>> response = requests.post(django_project_url,
...                          {'django_project': u'demo'})
>>> archive = tarfile.open(fileobj=StringIO(response.content), mode='r|gz')
>>> print '\n'.join(archive.getnames())
manage.py
demo/__init__.py
demo/settings.py
demo/urls.py
demo/wsgi.py
>>> archive.close()

You can get the content as a ZIP archive instead with the “accept” header:

>>> from zipfile import ZipFile
>>> response = requests.post(django_project_url,
...                          {'django_project': u'demo'},
...                          headers={'accept': 'application/zip'})
>>> print response.headers['Content-Type']
application/zip; charset=UTF-8
>>> archive = ZipFile(StringIO(response.content))
>>> print '\n'.join(archive.namelist())
manage.py
demo/__init__.py
demo/settings.py
demo/urls.py
demo/wsgi.py
>>> archive.close()

Tip

You can see all supported “accept” headers by requesting an unknown mime type:

>>> response = requests.post(django_project_url,
...                          {'django_project': u'demo'},
...                          headers={'accept': 'fake/mime-type'})
>>> response.status_code
406
>>> print response.content
406 Not Acceptable

The server could not comply with the request since it is either malformed or otherwise incorrect.


Supported mime types: */*, application/gzip, application/x-gzip, application/zip

See Directories for details about directory resources.

Dynamic tree template

Let’s work on directory resource dynamic-tree/.

>>> dynamic_tree_url = diecutter_url + 'dynamic-tree/'

It’s a directory. GET lists the templates it contains:

>>> response = requests.get(dynamic_tree_url)
>>> print response.content
.diecutter-tree
greeter.txt

greeter.txt is the same as greetings.txt example above:

>>> response = requests.get(dynamic_tree_url + 'greeter.txt')
>>> print response.content
{{ greeter|default('Hello') }} {{ name|default('world') }}!

diecutter-tree is a normal template, with a special name:

>>> response = requests.get(dynamic_tree_url + '.diecutter-tree')
>>> print response.content
[
  {% for greeter in greeting_list|default(['hello', 'goodbye']) %}
    {
      "template": "greeter.txt",
      "filename": "{{ greeter }}.txt",
      "context": {"greeter": "{{ greeter }}"}
    }{% if not loop.last %},{% endif %}
  {% endfor %}
]

It renders a list of templates, in JSON:

>>> response = requests.post(dynamic_tree_url + '.diecutter-tree',
...                          {'greeting_list': [u'bonjour', u'bonsoir']})
>>> print response.content
[

    {
      "template": "greeter.txt",
      "filename": "bonjour.txt",
      "context": {"greeter": "bonjour"}
    },

    {
      "template": "greeter.txt",
      "filename": "bonsoir.txt",
      "context": {"greeter": "bonsoir"}
    }

]

And guess what, this list of templates is used to render the directory resource:

>>> response = requests.post(dynamic_tree_url,
...                          {'name': u'Remy',
...                           'greeting_list': [u'bonjour', u'bonsoir']})
>>> archive = tarfile.open(fileobj=StringIO(response.content), mode='r:gz')
>>> print '\n'.join(archive.getnames())
bonjour.txt
bonsoir.txt
>>> print archive.extractfile('bonjour.txt').read()
bonjour Remy!
>>> print archive.extractfile('bonsoir.txt').read()
bonsoir Remy!
>>> archive.close()

Here, the greeter.txt template has been rendered several times, with different context data.

See Dynamic directory trees templates for details about dynamic tree templates.

References

[1]https://github.com/novagile/diecutter/
[2]http://python.org
[3]http://virtualenv.org
[4]http://sphinx-doc.org/ext/doctest.html
[5]https://pypi.python.org/pypi/WebTest
[6]https://pypi.python.org/pypi/requests

Client howto

This section focus on usage of diecutter service API, i.e. usage of diecutter from client’s point of view.

Files

Files are the main type of template resource.

Here is service’s API overview:

  • PUT: upload template file from client to server.
  • GET: retrieve raw template content.
  • POST: render single template file against context.
  • other HTTP verbs aren’t implemented yet.

Note

In the examples below, we’ll consider that a diecutter service is running at http://localhost:8106.

PUT

Put your template to the service:

$ echo "Hello {{ name }}" | curl -X PUT -F "file=@-" http://localhost:8106/hello.txt
{"diecutter": "Ok"}

Warning

Sometimes, you don’t want users to be able to PUT files on your server. That’s why diecutter service can be configured as “read only”. In that case, it is up to you to manage files that live in diecutter’s template directory (which is just a directory in the filesystem).

As an example, diecutter’s online demo is readonly, and templates are synchronized with source code on project’s repository.

GET

We can get the raw template we just created via PUT:

$ curl http://localhost:8106/hello.txt
Hello {{ name }}
POST

And we can render the template against some variables:

$ curl -X POST -d name=world http://localhost:8106/hello.txt
Hello world

Directories

Directories are the second type of template resource. They are collections of files and directories resources.

Here is service’s API overview:

  • PUT: directories are automatically created when you PUT a file in it. There is currently no way to create a whole directory with one request (uploading an archive as an example).
  • GET: list files in directory.
  • POST: render templates in directory against context, as an archive.
  • other HTTP verbs aren’t implemented yet.

Note

In the examples below, we’ll consider that a diecutter service is running at http://localhost:8106.

PUT

Let’s create some “greetings” directory with “hello.txt” and “goodbye.txt” inside:

$ echo "Hello {{ name }}!" | curl -X PUT  -F "file=@-" http://localhost:8106/greetings/hello.txt
{"diecutter": "Ok"}

$ echo "Good bye {{ name }}!" | curl -X PUT  -F "file=@-" http://localhost:8106/greetings/goodbye.txt
{"diecutter": "Ok"}
GET

GET lists files in directory:

$ curl http://localhost:8106/greetings/
hello.txt
goodbye.txt

Notice that, if you don’t set the trailing slash, you get the same list with folder name as prefix:

$ curl http://localhost:8106/greetings
greetings/hello.txt
greetings/goodbye.txt
POST

POST renders directory against a context:

$ curl -X POST -d name="world" -s http://localhost:8106/greetings | tar -zx

$ tree greetings
greetings
├── hello.txt
└── goodbye.txt
0 directory, 2 files

$ cat greetings/hello.txt
Hello world!

$ cat greetings/goodbye.txt
Goodbye world!

All files in directory are rendered with the same context data.

Like with GET, the trailing slash affects filenames: without trailing slash, filenames are prefixed with directory name.

Supported archives types: “accept” header

By default, POST requests return GZIP archives.

You can get the content as a TAR.GZ archive with the “accept” header:

$ curl -X POST --header "accept:application/zip" -d name="world" http://localhost:8106/greetings > greetings.zip
$ unzip greetings.zip
$ tree greetings
greetings
├── hello.txt
└── goodbye.txt
0 directory, 2 files

Tip

You can see all supported “accept” headers by requesting an unknown mime type:

$ curl -X POST --header "accept:fake/mime-type" -d name="world" http://localhost:8106/greetings
406 Not Acceptable

The server could not comply with the request since it is either malformed or
otherwise incorrect.


Supported mime types: */*, application/gzip, application/x-gzip,
application/zip

Posting input context data

When you perform POST requests on resources, you provide context data, i.e. variables and values.

Diecutter has builtin support for the following input content-types:

Diecutter expects data to be provided as the body of the request. “multipart/form-data” requests aren’t supported currently.

URL-encoded
# Default (implicit application/x-www-form-urlencoded content type).
curl -X POST -d 'who=world' http://localhost:8106/hello

# Explicit "application/x-www-form-urlencoded" content-type.
curl -X POST -d 'who=world' -H "Content-Type: application/x-www-form-urlencoded" http://localhost:8106/hello
JSON
curl -X POST -d '{"who": "world"}' -H "Content-Type: application/json" http://localhost:8106/hello
INI
# Flat.
curl -X POST -d 'who=world' -H "Content-Type: text/plain" http://localhost:8106/hello

# With sections.
cat > input.ini <<EOF
hello = world
[foo]
bar = baz
EOF
curl -X POST --data-binary '@input.ini' -H "Content-Type: text/plain" http://localhost:8106/foo
curl tips
  • Pass content of a file using @.
  • Pass content from standard input using @-.
  • When posting JSON or INI, use --data-binary.

References

[1]http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1
[2]http://json.org/
[3]https://en.wikipedia.org/wiki/INI_file

Variable-based output filenames

When rendering a directory, it is sometimes useful to use variables in the filenames to output.

Note

This is useless for single files, since most clients allow you to choose the name of the output file.

Setup templates with +variable+ in the filename:

echo "Focus on filename" | curl -X PUT -F "file=@-" http://localhost:8106/foo/+bar+.txt

The variables within + will be resolved and replaced by their value:

$ curl -X POST -d bar=baz http://localhost:8106/foo | tar -zt
foo/baz.txt

Note

This behaviour is disabled when using the template tree template.

This feature is meant for simple cases. If you need advanced things for filenames, use the template tree template.

Dynamic directory trees templates

Directory trees can be computed from templates.

Thus you can use all features of template engines to render filenames, select templates or even alter context.

Use cases

While rendering a directory...

  • skip some files based on variables ;
  • render a single template several times with different output filenames ;
  • alter template context data for some templates ;
  • use loops, conditions... and all template-engine features...
The template tree template

When you POST to a directory, diecutter looks for special ”.diecutter-tree” template in that directory. If present, it renders ”.diecutter-tree” against context, decodes JSON, then iterates over items to actually render the directory.

Except when rendering a directory resource, ”.diecutter-tree” template is a normal template resource file. Manage it as any other template file.

Example

Let’s explain this feature with an example...

Create a “dynamic-greetings” directory resource, which contains only one “greetings.txt” template:

echo '{{ greeting }} {{ who }}!' | curl -X PUT -F "file=@-" http://localhost:8106/dynamic-greetings/greetings.txt

Let’s make “dynamic-greetings” directory dynamic, by putting a .diecutter-tree template:

echo '[
  {% for greeting in greetings %}
    {
      "template": "greetings.txt",
      "filename": "{{ greeting }}.txt",
      "context": {"greeting": "{{ greeting }}"}
    }{% if not loop.last %},{% endif %}
  {% endfor %}
]
' | curl -X PUT -F "file=@-" http://localhost:8106/dynamic-greetings/.diecutter-tree

POST to .diecutter-tree returns a JSON-encoded list:

curl -X POST -d greetings=hello -d greetings=goodbye http://localhost:8106/dynamic-greetings/.diecutter-tree

[
  {
    "template": "greetings.txt",
    "filename": "hello.txt",
    "context": {"greeting": "hello"}
  },
  {
    "template": "greetings.txt",
    "filename": "goodbye.txt",
    "context": {"greeting": "goodbye"}
  }
]

JSON-encoded list items are dictionaries with the following keys:

  • “template”: relative path to a template, i.e. content to be rendered ;
  • “filename”: filename to return to the client ;
  • “context”: optional dictionary of context overrides.

Now let’s render the directory as an archive:

$ curl -X POST \
       -d name=Remy -d greetings=hello -d greetings=goodbye \
       http://localhost:8106/dynamic-greetings \
       | tar -zxv
$ tree dynamic-greetings
dynamic-greetings
├── hello.txt
└── goodbye.txt
0 directory, 2 files

$ cat hello.txt
hello Remy!

$ cat goodbye.txt
goodbye Remy!

Server howto

This section explains how to setup, configure and run a diecutter server.

Install, configure, run

This project is open-source, published under BSD license. See License for details.

If you want to install a development environment, you should go to Contributing to diecutter documentation.

Prerequisites
Install

Install “diecutter” package with your favorite tool. As an example with pip [2]:

pip install diecutter
Configure

Use diecutter’s online demo [3] to generate your local diecutter configuration:

# Adapt "YOUR_TEMPLATE_DIR"!
wget -O diecutter.ini --post-data "template_dir=YOUR_TEMPLATE_DIR" http://diecutter.io/api/diecutter.ini
Run

pserve (paster’s server) should have been installed automatically as part of diecutter’s dependencies. Use it to run the service:

pserve diecutter.ini --reload
Check

Check it works:

curl http://localhost:8106

You should get an “hello” with diecutter’s version.

References

[1]http://python.org
[2]https://pypi.python.org/pypi/pip/
[3]http://diecutter.io/

Framework

Diecutter is developped with extensibility in mind. Even if not stable yet, the idea is to build a default implementation upon a flexible framework. So that anyone can adapt the “templates as a service” pattern to his specific needs.

About diecutter

This section is about the diecutter project itself.

Vision

Diecutter is about file generation. Its primary goal is to provide an easy way to render templates against data.

Some leitmotivs:

  • focus on file generation.
  • in most use cases, don’t bother users with software installation and configuration.
  • when users have specific needs, they can easily setup a custom service.
API

API design drives diecutter’s development.

Server software

Diecutter provides a default implementation of the service, built with Python.

Framework

Diecutter is a framework. It must provide material that makes it easy to connect to other tools and easy to extend.

SAAS platform

Diecutter is developed with SAAS in mind. The online demo is a draft.

License

Copyright (c) 2012, Rémy Hubscher, Benoît Bryon. See Authors and contributors. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  • Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  • Neither the name of the diecutter software nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Authors and contributors

Changelog

This document describes changes between each past release. For information about future releases, check milestones [1] and Vision.

0.6 (2014-04-13)

Moved some parts of diecutter to external projects: core in piecutter, demo in template index and standalone template repositories.

  • Moved generic bits of diecutter’s core to third-party project ‘piecutter’.
  • Bug #100 - Files in tar.gz archives have a valid modification time (was epoch).
  • Feature #97 - Refactored diecutter’s demo index, so that it references templates from external repositories.
  • Render archive filename using filename_engine.
  • Added example configuration for cookiecutter and github.
  • Improved contributor guide.
  • Using tox to run tests. Development environment no longer uses zc.buildout.
0.5 (2013-07-19)

Proof of concept implementation of remote template loader and Django template engine.

  • Features #27 and #28 - Experimental support of remote templates, where templates are hosted in Github public repositories. The github service is published at http://diecutter.io/github. It accepts URLs like http://diecutter.io/github/<owner>/<project>/<revision>/<path/to/template/resource>
  • Features #57 and #29 - Public online SAAS at http://diecutter.io
  • Feature #66 - Introduced support of Django template engine. You can choose the (unique) template engine with diecutter.template_engine configuration directive. Default value is piecutter.engines.jinja:Jinja2Engine.
  • Bug #60 - PyPI renders README as HTML (was plain text).
  • Bug #65 - Contributor guide mentions dependency to virtualenv (was missing).
  • Refactoring #68 - Code follows strict PEP8. Using flake8 in tests.
0.4 (2013-07-17)

New feature (tar.gz archives) and marketing (talks).

  • Feature #4 - Added support of “accept” header for POST requests on directories: accepted types are ZIP (application/zip) and TAR.GZ (application/gzip).
  • Feature #53 - GZIP is now the default archive format when rendering directories. Use “diecutter.default_archive_type = application/zip” in configuration file if you need ZIP format as a default.
  • Refactoring #55 - Dropped support of Python 2.6. Tests are run against Python 2.7 only.
  • Refactoring #20 - Render functions return generator ; moved response composition (file/archive) into views via writers.
  • Feature #46 - Added content of talks in documentation: AFPY event and EuroPython 2013.
  • Feature #58 - Highlighted roadmap and vision in README.

See also milestone 0.4 on bugtracker [2].

0.3 (2013-04-16)

New features, documentation, bugfixes.

  • Bug #44 - Accepted arrays in URL-encoded POST.
  • Bug #40 - Setup CORS to allow AJAX requests on diecutter’s API.
  • Refactoring #37 - Used Jinja’s environment.
  • Bug #34 - Frozen buildout configuration file for development environment.
  • Features #31 and #43 - Published diecutter’s demo online. Online API URL changed.
  • Feature #24 - Added Sphinx documentation template in diecutter’s demo.
  • Feature #23 - Added diecutter’s Sphinx documentation.
  • Feature #10 - Added dynamic tree template.

See also milestone 0.3 on bugtracker [3].

0.2 (2013-02-22)

Maintenance release, implementation refactoring, tests.

  • Refactoring #22 - Added tests.
  • Bug #17 - Sort directories alphabetically.
  • Bug #13 - Fixed “diecutter.readonly” which was always True.

See also milestone 0.2 on bugtracker [4].

0.1 (2013-01-29)

Initial release.

  • Bug #11 - On POST requests, handle empty content-type as “application/x-www-form-urlencoded”.
  • Feature #8 - Support INI files as input for POST requests.
  • Feature #3 - Use a configuration file outside diecutter’s code.
  • Feature #2 - If “readonly” option is True, forbid PUT requests.
  • Feature #1 - Pass a “diecutter” context variable to templates, containing data such as “diecutter.api_url”, “diecutter.version” and “diecutter.now”.
  • Feature - Diecutter service renders directories as ZIP archives.
  • Feature - Diecutter service renders files.

See also milestone 0.1 on bugtracker [5].

Notes & references

[1]https://github.com/diecutter/diecutter/issues/milestones
[2]https://github.com/diecutter/diecutter/issues?milestone=7&state=closed
[3]https://github.com/diecutter/diecutter/issues?milestone=6&state=closed
[4]https://github.com/diecutter/diecutter/issues?milestone=2&state=closed
[5]https://github.com/diecutter/diecutter/issues?milestone=1&state=closed

Contributing to diecutter

This document provides guidelines for people who want to contribute to the project.

Create tickets

Please use the bugtracker [1] before starting some work:

  • check if the bug or feature request has already been filed. It may have been answered too!
  • else create a new ticket.
  • if you plan to contribute, tell us, so that we are given an opportunity to give feedback as soon as possible.
  • Then, in your commit messages, reference the ticket with some refs #TICKET-ID syntax.

Use topic branches

  • Work in branches.
  • Prefix your branch with the ticket ID corresponding to the issue. As an example, if you are working on ticket #23 which is about contribute documentation, name your branch like 23-contribute-doc.
  • If you work in a development branch and want to refresh it with changes from master, please rebase [2] or merge-based rebase [3], i.e. do not merge master.

Fork, clone

Clone diecutter repository (adapt to use your own fork):

git clone git@github.com:diecutter/diecutter.git
cd diecutter/

Setup a development environment

System requirements:

Execute:

git clone git@github.com:diecutter/diecutter.git
cd diecutter/

Usual actions

The Makefile is the reference card for usual actions in development environment:

  • Install development toolkit with pip [6]: make develop.
  • Run tests with tox [7]: make test.
  • Build documentation: make documentation. It builds Sphinx [8] documentation in var/docs/html/index.html.
  • Release diecutter project with zest.releaser [9]: make release.
  • Cleanup local repository: make clean, make distclean and make maintainer-clean.

Notes & references

[1]https://github.com/diecutter/diecutter/issues
[2]http://git-scm.com/book/en/Git-Branching-Rebasing
[3]http://tech.novapost.fr/psycho-rebasing-en.html
[4]http://python.org
[5]http://virtualenv.org
[6]https://pypi.python.org/pypi/pip/
[7]https://pypi.python.org/pypi/tox/
[8]https://pypi.python.org/pypi/Sphinx/
[9]https://pypi.python.org/pypi/zest.releaser/

FAQ

Here are some frequently asked questions...

Why “diecutter” name?

A “die cutter” is a machine that cuts materials to produce shapes, from molds.

Here, the diecutter web service produces files from data and templates.

Does it replaces my web framework (Django) templates?

diecutter is not meant to replace web framework’s template engines! Diecutter is meant to replace file generators for configuration or scaffolding use cases.

Even if processes are really close, environment and needs aren’t. As an example, diecutter service won’t be as efficient as web frameworks internal templating systems.

So, even if, in theory, you could use diecutter as a template engine to render pages of a website, it is discouraged.

Indices and tables