The project Python package dependencies are managed by the "Poetry" tool.
Previously, the version of Poetry was not managed in any way.
The GitHub Actions workflows used whichever version of Poetry happened to be installed on the runner machine. This meant
that the GitHub Actions workflows could break at any time through the Poetry installation on the runner machine being
updated to an incompatible version.
The contributors used whichever version of Poetry happened to be installed on their machine. This meant that they might
get different results from that produced by the environment of the GitHub Actions workflows.
The better solution is to take the same approach for managing the Poetry dependency as is done for the project's other
dependencies:
* Install a specific version of Poetry according to a single source of versioning data.
* Use the Dependabot service to get automated update pull requests.
The logical place to define the Poetry package dependency version is in pyproject.toml, as is done for all other Python
package dependencies.
Dependabot has support for two different forms of dependency data in the pyproject.toml file:
* Original Poetry data format, under the `tool.poetry` table
* PEP 621 format data, under the `project` table
Since Poetry can't be used to manage itself (it is instead installed using the "pipx" tool), the obvious approach would
be to define the Poetry dependency via the `project` table in the file. However, this is not possible because if a
`tool.poetry` table is present in pyproject.toml, Dependabot ignores the dependencies data from the `project` table. So
it is necessary to place the data for the Poetry dependency under the `tool.poetry` table of the file. A special
dependencies group is created for this purpose. That group is configured as "optional" so that it won't be installed
redundantly by `poetry install` commands.
Unfortunately pipx doesn't support using pyproject.toml as a dependency configuration file so it is necessary to get the
Poetry version constraint for use in the dependency argument of the `pipx install` command by parsing the project.toml
file.

Projects may use data files written in the TOML language. A common example of such is the `pyproject.toml` file present
in projects that use the Poetry Python package management tool (either for project code dependencies, or development
tools).
In cases where the TOML content is edited directly by human contributors, it will be useful to provide code formatting
infrastructure for TOML files, and to enforce consistent formatting. This is easily accomplished by adding TOML support
to the existing code formatting infrastructure via the "prettier-plugin-toml" plugin for the Prettier formatting tool.
Poetry's `poetry.lock` file is also written in the TOML language. This file is automatically generated and never
manually edited. In this case, the automatically generated content is accepted as-is. So Prettier is configured to
exclude the `poetry.lock` file from formatting.