Feature request: Specifying version

[okuramasafumi]

Sometimes we'd like to specify the version of Codespell to control dictionaries. c.f. this commit in Rails.
Could we add the ability to specify the version of Codespell to install?

[akien-mga]

I'd like this too for https://github.com/godotengine/godot

The action seems to use the latest dictionary from https://github.com/codespell-project/codespell, and while that's nice, it means that we start getting PRs failing due to typos not introduced by these PRs. It's a bother to contributors, and particularly annoying for stable branches where we don't necessarily run codespell daily so bugfix updates also fail CI.

[mateusoliveira43]

I saw the problem of PRs failing due to typos not introduced by these PRs in a project I work (of course, because we use @master instead of a fixed version, but we would like to receive updates with more frequency).

One suggestion would be to create an automation that after a new release in https://github.com/codespell-project/codespell, a new release would be created here. This way, we can use dependabot PRs to update the action regularly, and fix the new typos within those PRs.

[skoudoro]

+1 for this request.

and question, How do I use the latest release : codespell v2.3.0 ? Many new features available that we would like to use.

Thank you for your future feedback

[ilyagr]

For me, the best solution would be if a given version of the Codespell action always used a fixed version of the codespell tool.

Technically, using a == version in https://github.com/codespell-project/actions-codespell/blob/master/requirements.txt . If we trust codespell to follow semantic versioning, it'd be OK to use something like codespell>=2.4,<2.5,

Would it be realistic to make a reslease of the action per every release of codespell (or at least every non-patch release)? Would this work for other people's usecases?

If that's too much trouble, the ability to specify the tool version in the Codespell action config would also help a lot.

---

A workaround that comes to mind is to use the uv action and then use uv to run codespell. This could use uv tool run codespell --from codespell>=2.4,<2.5, or uv run and a project setup in pyproject.toml + uv's lockfile. This would require creating a config file for codespell as well.

[deivid-rodriguez]

In case it helps anyone, our solution was to replace this action with actions/setup-python plus manually installing a requirements.txt file that pins the codespell version, and manually running it.

We also added a Dependabot configuration to keep this requirements file up to date, so that, while we don't get randomly failing CI whenever codespell releases a new version, we do get some heads up through a Dependabot PR about new codespell releases, so that we can start using new dictionaries at our own pace.