New cookiecutter.json format and more for cookiecutter 2.0

[klamann]

Hi, I'm with Alexander Thamm GmbH, we've been using cookiecutter internally for some time now and we also have an open source Python template that we're quite fond of. Anyway, while working on our template we've come across a few limitations in cookiecutter and we would like to contribute code to resolve them. Features that we're interested in are

• specifying metadata (template name, version, url, description, etc.) in cookiecutter.json
• specifying version compatibility (required cookiecutter or Python version)
• more sophisticated definition of variables (proper descriptions, input validation, skipping questions based on previous input, etc.)
• pretty terminal output and input that works with all common terminals
• undo/redo function for terminal prompts

We're exited to see that things are going forward with cookiecutter now and that the release of version 2.0 (#1555) is in the pipeline. In the past couple of weeks we've been working on the new context format (see #1566) and we're also interested in contributing code to cover some of the other features from the list.

What I'd like to discuss here is: Are you interested in code submissions that cover the changes I mentioned above? Are you open to the idea to change the cookiecutter.json schema in a non-breaking way, similar to the changes proposed by hackebrot #848 and eruber #1008? Do you think any of these changes could be included in cookiecutter 2.0 or would you rather target a later release?

[simobasso]

Hey @klamann 👋 !

Thank you for the amazing and huge work 🚀 !

As stated in #1566, we have a full focus on bugs and the release itself, but yes, this is a long-waited feature.

I've just approved the pipeline, and I'll mark this one for the next milestone.

The pr seems pretty big and contains many side effects; I'll continue the review directly on the pr, but what do you think about splitting the pr into small feature branches?

Thanks again 🙏

[leoank]

+1 for this feature! Any updates on this? Is it going to be a part of 2.0 release?

[klamann]

we've been asked to split up the work into smaller PRs, so we did that and are currently waiting for PR #1580 to be approved. Unfortunately, there hasn't been much feedback from the maintainers in a while.

[leoank]

thanks @klamann for the update and your work on this PR!

@simobasso thanks for you awesome work on this project! Do you need some help with merging this feature? It would be great if you can add this to 2.0 release!

[jensens]

Hi @klamann,
as new co-maintainers @ericof and I are now reviewing open PRs and ideas.
Due to special circumstances the project stalled for a while. I hope you're motivated to follow up on this.

Personally I like the idea of a more verbose JSON and also having it validated as in #1580! It is probably a major change, even if non-breaking, right?

Since I do not have the overall vision where this will end up, I would ask if we may schedule a video session on the Cookiecutter Discord Server - and everyone (specifically @simobasso @leoank but everone else too) interested in this topic is invited to join as well.

[klamann]

Hi @jensens, glad to see that this topic is getting some attention. I would definitely like to see this feature merged at some point, but I would need a stronger commitment from the current maintainers to invest more time in this. I'd be happy to meet for a video session; I'm on vacation though starting tomorrow, I'll be back on June 13th. Shall we meet sometime during that week?

The change is inteded to be non-breaking, though there is a very narrow edge case where it wouldn't quite work, since the current schema is valid for basically any input and we need some way to differentiate between the old and new schema. But I'd be surprised if it would impact any of the popular cookiecutter templates.

[ark-]

Could you compare against an edition in the cookiecutter.json. If, for example, "__cookiecutter.edition__" is "2" then use the new schema. If this is omitted then assume schema 1?

Rust does something similar in their rust editions. https://doc.rust-lang.org/edition-guide/editions/index.html