Cookiecutter: Use YAML for cookiecutter configuration

[Varriount]

The current "configuration" file for cookiecutter templates uses the JSON format. While this is fine for simple templates, it quickly falls apart for more complex requirements:

• Limited prompt capabilities (only single-line freeform input or single-choice selection)
• No comments
• No multi-line strings (useful for long jinja templates)

Using YAML allows for tags to be used, which allows for tagging a data type with extra information (such as whether a list should be multiple-choice or single-choice). YAML also allows for comments and multi-line strings (including heredocs)

Issues that might be better resolved using features from YAML:

• #138 (Using tags to denote input type)
• #126 (Using a tag to denote that an input is a boolean type)
• #853 (Using tags to denote that an input is a sensitive string)
• #433 (Using objects marked with a tag, to differentiate from regular maps)

[luzfcb]

relevant issue about YAML: https://github.com/audreyr/cookiecutter/issues/743

another blocker: https://github.com/audreyr/cookiecutter/pull/848#issuecomment-259575460

[luzfcb]

Comparison of configuration file languages:
https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f

[Varriount]

The main draw for YAML is the ability to tag pieces of data in the document. The next-best format would be TOML (which at least has comments and multi-line strings).
Using the INI file format would be the worst choice. Every project that uses it eventually runs into some sort of limitation (everything's a string or possibly a list, limited nested) and has to create hacks.

[brutus]

I came here looking for YAML support, because writing JSON is so tedious. It's unfortunate to see YAML support was dropped, but understandable.

I have to agree with @Varriount, though, INI support would be the worst choice as an alternative format — it is not standardized in any way and not that big of a gain in terms of writability. __TOML__ might be a way better alternative.

I think __HJSON__ might be an even better alternative. We stick with JSON and get a lot of nice writability improvements. Especially for those used to Python syntax. It's basically JSON for humans :wink:

• http://hjson.org/
• https://pypi.python.org/pypi/hjson

[techdragon]

@Varriount TOML is likely to be a better long term choice since future versions of packaging tools such as pip and setuptools will be using TOML since it was chosen as the format for the future Pipfile feature.

Using TOML will mean at some point in the future you can rely on TOML support coming out of the box with the users Python install just like pip does now. (for current versions of python)

[Varriount]

@techdragon Neat. Where are these plans for pip posted?

[pfmoore]

PEP 518 is where the new format using TOML was specified. To parse the format, pip vendors the pytoml library - the vendored code is not available outside of pip, though. I'm not aware of any proposal to add TOML support to the standard library, although I guess it's a possibility at some point.

[hackebrot]

Hi @Varriount, @brutus, @techdragon! 👋

Thanks for the suggestion and your feedback. 🙇

Moving to a new file format for cookiecutter.json would mean a lot of ongoing work for Cookiecutter maintainers. That being said, this would only be justified if we also add config features that people have requested for a long time and add new capabilities for template authors. See #848 for more information on this.

Moving to a new file format for cookiecutter.json will require some sort of real sponsorship, be it financial compensation or an employer who will provide time. If this something that you and your company would like to provide, please see the support this project section or comment here. Thank you! 🙇

[umeboshi2]

Is is really necessary to "move" to a new format just to support a cookiecutter.yml file? Wouldn't it be just as easy to just detect the presence of the file and use it? Why not just make it optional and let template maintainers deal with the problems that may occur?