You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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: jazzband/pip-tools#1863 (comment).
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.The text was updated successfully, but these errors were encountered: