Conversation
Resolve the base repository through a new `get_repository_or_exit` helper, which catches `RepositoryNotFound` and `RepositoryCloneFailed` and displays an error screen instead of letting a traceback reach the user. `RepositoryNotFound` is raised when no candidate directory contains a `cookiecutter.json` file at its root, and `RepositoryCloneFailed` when the requested tag does not exist -- the latter is the case the error message points at, so both need to be handled. Keeping the handling in a helper also holds `cli` under the McCabe complexity limit enforced by ruff. Pin the default `--tag` to `20260810.1`. Refs #210
| typer.Option("--output-dir", "-o", help="Where to generate the code."), | ||
| ] = None, | ||
| tag: Annotated[str, typer.Option(help="Tag.")] = "main", | ||
| tag: Annotated[str, typer.Option(help="Tag.")] = "20260810.1", |
There was a problem hiding this comment.
@ericof Hmm. So if we need to release a bugfix for the 1.x templates, how will we do that? We'll need to make a new release of cookieplone 1.x with a new default tag here? And what happens once we are making releases of the next templates as well? Using calver here makes it hard to have 2 parallel sets of releases for 1.x and next.
Answering my own question: we don't intend to maintain the 1.x templates once next is released. The goal here is to make sure that the last cookieplone 1.x release doesn't pick up the new templates that it doesn't know how to handle, not to have 2 active maintenance branches.
By the way, something went wrong with the release notes: https://github.com/plone/cookieplone-templates/releases/tag/20260810.1
2 participants
What
Display an error screen, instead of a traceback, when the template repository cannot be used, and pin the default
--tagfor the 1.x series.Why
cookieploneresolved the base repository with a bare call toget_base_repository, so any failure surfaced as a rawcookiecuttertraceback.Two distinct failures reach that call:
RepositoryNotFound— no candidate directory contains acookiecutter.jsonfile at its root (determine_repo_dirchecksrepository_has_cookiecutter_jsonfor each candidate before raising).RepositoryCloneFailed— the clone succeeded but the requested tag does not exist (cookiecutter.vcs.cloneraises this on a failed checkout).The second is the case the error message actually steers the user toward ("use another tag"), so handling only the first would leave that advice unreachable.
How
get_repository_or_exithelper incookieplone/cli.pywrapsget_base_repository, catches both exceptions, renders an error screen, and exits with status1. Keeping the handling in a helper also holdscliunder the McCabe complexity limit enforced by ruff.console.error_screenrenders a message inside the standard cookieplone panel.--tagpinned to20260810.1, an existing tag ofplone/cookieplone-templates.Tests
tests/test_cli.py— parametrized overRepositoryNotFoundandRepositoryCloneFailed; asserts exit code1and that the error screen is displayed.tests/utils/test_console.py— renders the panel through a recordingrich.Consoleand asserts its title and message.Verified the
RepositoryCloneFailedcase fails without the fix by temporarily narrowing theexceptclause, then restoring it.Full suite: 280 passed.
make lintclean.Notes
Targets the
1.xmaintenance branch.Refs #210