How to keep the template repository a fully functioning project?

[Yura52]

Hi! I want my template repository to be a fully functioning project itself to make it testable and usable as an ordinary project. What I don't understand is how to deal with project-specific files in such a case. For example, consider pyproject.toml. On the one hand, it must be a full-fledged working thing in the template repository. On the other hand, I want to: (1) on copier copy, update the project name and project version in pyproject.toml; (2) on copier update, skip this file.

(2) seems to be solved by the "skip if exists" setting. However, how do I solve (1) without introducing pyprojec.toml.jinja which would lead to duplication between pyproject.toml and pyprojec.toml.jinja ?

P.S. The following discussion seems to be relevant:
https://github.com/orgs/copier-org/discussions/1626

[sisp]

I don't see how what you're trying to do is possible. For example, how do you intend to have a fully functional pyproject.toml file whose project name is replaced when executing copier copy? Copier uses Jinja templating for this purpose, but this means a templated pyproject.toml file is typically not functional. I imagine you might be thinking along the lines of string substitution instead of real templating, but this is too limiting for many real-world Copier templates. For example:

• copier.yml:

  python_versions:
    type: str
    help: Your supported Python versions
    choices: &python_versions
      - "3.10"
      - "3.11"
      - "3.12"
      - "3.13"
      - "3.14"
    multiselect: true
    default: *python_versions
    validator: >-
      {%- if not python_versions -%}
      At least one Python version required
      {%- endif -%}

• pyproject.toml.jinja:

  [project]
  ...
  classifiers = [
    "Programming Language :: Python",
    "Programming Language :: Python :: 3",
  {%- for v in python_versions %}
    "Programming Language :: Python :: {{ v }}",
  {%- endfor %}
  ]
  requires-python = ">={{ python_versions | first }}"
  ...

I don't see how to make this excerpt of a pyproject.toml file both functional as-is and useful for generating a project.

I think the project template should always be separated from the overall repo boilerplate. For example, I maintain a test suite that tests all kinds of variants of generated projects based on different answers to the questions. At the same time, the project template also contains a test suite starter. But the two test suites are very different.

A Copier template repo layout for a Python project template might look something like this:

.
├── .github
│   └── workflows
│       ├── ci.yml
│       └── release.yml
├── template
│   ├── .github
│   │   └── workflows
│   │       ├── ci.yml.jinja
│   │       └── release.yml.jinja
│   ├── src
│   │   └── {{ package_name }}
│   │       └── __init__.py.jinja
│   ├── tests
│   │   └── conftest.py.jinja
│   ├── {{ _copier_conf.answers_file }}.jinja
│   ├── pyproject.toml.jinja
│   └── README.md.jinja
├── tests
│   ├── e2e
│   │   ├── conftest.py
│   │   ├── test_basic.py
│   │   ├── test_merge_request.py
│   │   └── test_release.py
│   ├── conftest.py
│   └── test_template.py
├── copier.yml
├── pyproject.toml
├── README.md
└── uv.lock

I typically use test-driven development for Copier templates, this has worked very well for me so far.

I'm curious what you think and learn more about your use case.

[Yura52]

Thank you for the quick reply! I guess my main question falls under the "how do I develop the template itself" umbrella.

In more detail, in my academic lab, we have a template repository for research projects. People start their projects by cloning the template repository, reinitializing it as a new independent repository and tweaking all necessary settings (such as the aforementioned project settings in pyproject.toml). This is currently implemented via custom scripts, and I am looking for specialized templating tools. Ideally, we want to be able to pull updates from the template to actual projects, so Copier looks like an interesting option.

Importantly, our template repository is a fully functioning "project" itself that is almost unaware of its template role. This makes things easier for developing the template itself, as it is a regular Python project, and anything from uv run to language servers just work. Conceptionally, I fully understand your suggestion and the separation between template repositories and projects. However, it seems that this approach introduces its own complexity that we currently don't have, so this is a sort of a trade-off :)