Yes, definitely.
See my suggestion on Support better prompts #30 for a more backwards-compatible option for a more complex config format. This also allows for more complex prompt logic, typed Jinja variables (that couldn't be autodetected), and maybe validation logic as well. See also Allow boolean config variables #126 and Add support for typed template variables #138.

If we did change the config to look something like what I propose in Support better prompts #30, we could take any "configuration" data and wrap that up in a top-level object, so you might have something that looked like the following:
```
{
    "__config__": {
        "root": "{my_root_template_variable}",
        "encoding": "utf-8"
    },
    "full_name": {
        "default": "Audrey Roy",
        "prompt": "Your full name?"
    },
    "email": "audreyr@gmail.com",
    "repo_name": {
        "default": "boilerplate",
        "prompt": "Lowercase, spaceless, version of your repo name?",
        "help_text": "This should be a name that is importable as a Python package."
    }
}
```
This keeps the configuration stuff mostly separate, and clearly delineated from template/prompt variables, and also allows backwards compatibility with the current format (remove __config__ to get the list of prompt vars, and check whether the values of each prompt var are a simple string or an object. I really think we should avoid having two separate formats for config files, which is what you seemed to be suggesting above. Apologies if I misunderstood that.
I was kind of blue-skying before, but I came across a use case the other day where it would have been nice to be able to have three individual files generated from a tool like cookiecutter, so I think supporting this case makes sense. And I think allowing for a list of root templates as you suggest is a good way to go.

Thanks for the input. I really think this should be hashed out pretty thoroughly before moving forward as it's a pretty large change, and it's good to get some feedback here.

Do you have any ideas on my comments above about the current default behavior? The current situation is not terribly well defined (since it depends on the order in which cookiecutter finds things), so I'm not a huge fan of it, but I'm also leery of breaking existing code which may rely on it.

cookiecutter.repo_name is hardcoded as app root #10

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions