Cookiecutter/Jinja Support for Remote Templates?

[dcernag]

Problem statement

When using the remote templates feature, files provided by the remote template (such as pyproject.toml) are currently treated as a literal overlay. This means that dynamic templating using Cookiecutter/Jinja variables (e.g., {{ cookiecutter.project_name }}) is not processed within these files.

I've experienced a couple pain points when authoring/using remote templates:

• Static pyproject.toml content: Key fields like project.name cannot be dynamically set based on user input during create. Additionally, other configurations within pyproject.toml (e.g., tool.agent-starter-pack settings, dependencies) cannot be conditionally templated based on selected options.
• Inconsistent Experience: This behavior differs significantly from how built-in templates are processed, where pyproject.toml is dynamically generated and fully customized.

Current Workaround

Currently, I'm asking users to manually update their pyproject.toml after project creation.

Proposed Solution / Question

Is there any plan to support full Cookiecutter/Jinja2 templating for all files within remote templates? This would allow for dynamic configuration and eliminate the need for manual post-creation edits, providing a much smoother and more consistent user experience.

If full templating is not planned in the near future, are there any recommended workarounds or best practices for remote template creators to achieve dynamic pyproject.toml generation or other conditional file content based on create command options?

[eliasecchig]

Thanks for the detailed feature request! This is a valid use case.

The challenge here is that it would require double Jinja templating - one pass for the base template, another for the overlay. We can't simply enable Jinja for all remote template files because it could cause issues with files like notebooks or other content that might contain Jinja-like syntax unintentionally.

Any implementation would need to be explicit/opt-in, perhaps via a configuration flag or file pattern.

Would you be open to submitting a PR for this? Happy to discuss the implementation approach if so.

[dcernag]

Thanks @eliasecchig, makes sense to only use templates for certain stuff and agreed that the unnecessary complexity my first suggestion may introduce is not worth it rn.
We defaulted to use official templates for now. I would love to submit a PR but don't see it feasible this/next month. Will circle back and if no-one has taken it i'll let you know :)