Shared variables
See original GitHub issueIn order to factor out common calculations, especially amongst file and directory names, it would be useful to be able to define variables in copier.yml
whose values are calculated based on answers or other variables.
For example, when creating a template for a Java project, based on the name of the project, I would like to calculate the name of the root package, and also the path of the root package.
project_name:
type: str
default: hello-world
root_package:
type: str
default: "org.example.{{ project_name | title | regex_replace('-', '.') }}"
root_package_dir:
type: str
default: "{{ root_package | regex_replace('.', '/') }}"
The root package variable would be referred to by multiple files.
The root package directory must be calculated this way since you cannot have a filename with a slash (/
).
Describe the solution you’d like
I suggest adding support for defining variables in copier.yml
in a similar way as defining questions. The two are distinguished in some way, perhaps by a prefix such as a double underscore (__
) or by a key such as hidden: true
. I suggest that it be possible to mix defining variables and questions such that a question definition can refer to prior variables.
Describe alternatives you’ve considered This feature is called Private Variables in Cookicutter.
An obvious workaround is to define questions with default values. This is unsatisfactory because this forces users to read the trivial question and decide to hit the enter key, which adds unnecessary overhead and
Additional context The given example refers to Java, but templates for other programming languages, including Python, could have similar issues.
Issue Analytics
- State:
- Created a year ago
- Comments:6 (3 by maintainers)
@FlorianLudwig
when: false
can lead to surprising behavior, see https://github.com/copier-org/copier/discussions/678#discussioncomment-2822746 (just for your information, not trying to prevent you from usingwhen: false
if that works for you 🙂 )For the time being, you already know the workarounds we have. However, you inspired me to write #718. Let’s close this one. Thanks!