Hi, I'd like to request a feature that is a missing bit for a specific use case.
For projects that use mass maintenance techniques similar to https://github.com/jaraco/skeleton (where there's an upstream Git skeleton that is periodically git merged into downstream), it's important for tools to have their own config files that are auto-detected. The reason is that this maintenance approach causes lower number of merge conflicts compared to having many tool configs in one file.
Examples of modern tools supporting separate non-pyproject config locations (even in the post-PEP 518 world) in the TOML format are Hatch, pip-tools, Poetry, Ruff, Towncrier.
Having experience taking part in implementing this for pip-tools, and leading the review/debates, I want to point out one implementation detail that may come up. It's the naming and the presence of the tool section in a non-pyproject config.
We debated the following options:
Only having it in pyproject.toml as [tool.<tool-name>] and bare keys in the .<tool>.toml one.
Having [<tool-name>] in .<tool>.toml.
Having [tool.<tool-name>] in .<tool>.toml.
We chose the third option. This allows copying the config section across files without changes. It also allows co-existing with other tools. It's also consistent, so the config reader doesn't have to implement multiple fallbacks for reading the config.
This I why I propose having .cython-lint.yml, which would take precedence over pyproject.toml (even when it's empty!). The section header for this file would be the same — [tool.cython-lint].
P.S. Many tools also have a --config CLI flag for passing arbitrary file paths. It's not necessary for my use case, but some people may want it at some point.
Hi, I'd like to request a feature that is a missing bit for a specific use case.
For projects that use mass maintenance techniques similar to https://github.com/jaraco/skeleton (where there's an upstream Git skeleton that is periodically
git merge
d into downstream), it's important for tools to have their own config files that are auto-detected. The reason is that this maintenance approach causes lower number of merge conflicts compared to having many tool configs in one file.Examples of modern tools supporting separate non-pyproject config locations (even in the post-PEP 518 world) in the TOML format are Hatch, pip-tools, Poetry, Ruff, Towncrier.
Having experience taking part in implementing this for pip-tools, and leading the review/debates, I want to point out one implementation detail that may come up. It's the naming and the presence of the tool section in a non-pyproject config. We debated the following options:
pyproject.toml
as[tool.<tool-name>]
and bare keys in the.<tool>.toml
one.[<tool-name>]
in.<tool>.toml
.[tool.<tool-name>]
in.<tool>.toml
.We chose the third option. This allows copying the config section across files without changes. It also allows co-existing with other tools. It's also consistent, so the config reader doesn't have to implement multiple fallbacks for reading the config.
This I why I propose having
.cython-lint.yml
, which would take precedence overpyproject.toml
(even when it's empty!). The section header for this file would be the same —[tool.cython-lint]
.Here are some of our earlier discussions: https://github.com/jazzband/pip-tools/pull/1863#discussion_r1188761535.
P.S. Many tools also have a
--config
CLI flag for passing arbitrary file paths. It's not necessary for my use case, but some people may want it at some point.