new: add yaml parser for projects config.

[vaab]

Hum, I've just seen I'm not the first to provide this (see #359 )

I have no preference on which implementation is best.

[msabramo]

Oops. Neither this nor #359 merges cleanly now.

[vaab]

Rebased the PR, added one more test... can you consider looking at this before another commit breaks it again ? (I have several other PR waiting for this one also). Or if you have concerns about my PR please voice them. Many thanks !

[hackebrot]

Can you please rebase your branch on top of our master?
Your forks local master is 152 commits behind.

Thanks 🙇

[vaab]

Rebased

[msabramo]

Cool

[vaab]

Please note that the test are failing due to an issue I've raised #434 and this is unrelated to my patch.

https://ci.appveyor.com/project/audreyr/cookiecutter/build/1.0.464/job/gd2y5dl06014rvua

[michaeljoseph]

Could we just raise SyntaxError instead of adding another custom exception?

[vaab]

Don't we need to offer the possibility to make a distinction between standard SyntaxError (which could stem from any python code or other non-controlled places -- like libraries --) and what was identified as ParsingError from one of the parsers of this module (and that can not be generated by any other code as it's unique to this task) ?

The code already rely on this in this very patch to display an error message on what was identified as syntax error while parsing config file whatever the format of the config file. It's meant as a generalization of sub-parser's parsing exceptions (namely ScannerError for Yaml, and ... ValueError for json). Without this exception, I believe we are at risk of displaying a misleading error message to the user/dev, catching unrelated SyntaxError that could be casted in any context of any inner libraries.

Besides this rationale, it did seem rather natural for the project to not shy upon creation of custom exceptions as you can witness in the lines preceding the definition of this exception.

[michaeljoseph]

Ok, convinced 👍

[shaleh]

What is holding this up? There was plenty of progress and then nothing......

[pydanny]

What's holding this up is that we're all volunteers. No one gets paid to work on this project.

Also, we had to switch to Poyo (which involved @hackebrot creating it) for YAML parsing because PyYaml wasn't fully cross-platform (neither is ruamel.yaml). Some of us (or at least me) also think we should stick with the JSON format, or the HJSON (http://hjson.org/) alternative.

[shaleh]

This was intended as a gentle poke to see if anyone still cared. I get Open Source and volunteerism :-)

Thanks for the link to hjson. I had not seen that. Comments and the error from a dangling comma are the two big things I dislike about json.

[hackebrot]

I struggle to read a "gentle poke" from "nothing......". 😒

We released a Cookiecutter 1.4.0 just recently, which comes with loads of improvements, such as support for jinja2 extensions and a lightweight yaml parser to overcome the numerous problems with known Python yaml parsers. We've also put a lot of effort in overhauling the test suite to not rely on network connection.

That being said, I don't think the file format is what's important here. There have been a bunch of requests and also efforts of the core team to move to a more advanced context file. Things like input validation, types, help messages, nested values.

If done right, it doesn't really matter if we go with json, yaml, toml, hjson or even ini files. All it takes is a rock solid parser which runs on Python 2.7, 3.3, 3.4, 3.5 and PyPy on Linux, OS X and Windows (json being builtin is an obvious solution in that regard) and a well-documented context format 😉

[pydanny]

#743 moves us away from YAML. From there we can explore other formats for configuration.