v8.1.0 (2023-07-10)

[yajo]

Feat

• add support for computed values via skipped questions (feat: add support for computed values via skipped questions #1220)
• add --trust as a less scary alternative to --UNSAFE (feat: add --trust as a less scary alternative to --UNSAFE #1179)
• add OS identifier to render context

Fix

• pydantic: add upper dependency bound to fix unlocked installations

Refactor

• request answers imperatively instead of implicitly via impure property

---

This discussion was created from the release v8.1.0 (2023-07-10).

[Carl132]

Very happy about the decision to replace --UNSAFE with --trust - my users would've freaked out!

[blakeNaccarato]

Is this the last release of Copier that will support Pydantic v1? I notice that master pins Pydantic v2 at minimum, which may cause some trouble for me if I decide to keep Copier in the same development virtual environment as projects which use Copier templating. I will either have to migrate those projects to Pydantic 2, or split out Copier usage into a tox/nox job, or use globally installed Copier via pipx or something.

Would dropping Pydantic 1 support be a big enough change that the next version of Copier should be v9? It seems like it to me, but it's a matter of opinion.

copier/pyproject.toml

Line 39 in 9fc58b8

pydantic = ">=2.0.3"

[yajo]

Would dropping Pydantic 1 support be a big enough change that the next version of Copier should be v9?

https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api

According to that, it's not a major change.

[blakeNaccarato]

I see, that is sensible reasoning.

I do think that SemVer's advice implicitly assumes a sane dependency isolation system for a given language, which Python lacks 😅. Whether the next release of Copier is patch/minor/major, I think the dropping of Pydantic v1 deserves significant emphasis in the release notes.

I see a way forward, but it would require a change in my consumption of Copier for some projects. Even though there is no "API change", it does in my opinion reflect a change in "the effective application programmer's interface" due to the coupling of dev and project tooling in many project structures. But perhaps that coupling is my failing and maybe does not reflect most dev setups.

How that is reflected in the version scheme is no big deal, I just wanted to express a desire for emphasized communication on the dropping of Pydantic v1 in whichever release that happens. Thanks!

[yajo]

I generate the release notes using an automated tool that uses the commits, and the pydantic 2 support commit is already included with a format that intentionally shouldn't appear in the changelog. I did that because I usually never indicate dependency changes in the changelog. I'll see what can be done. In any case, just know that the next release, whatever the number, will use pydantic 2.