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
As a (mostly) python user, I've applied taplo (via the conda-forge redistribution of taplo-cli (disclaimer: maintainer) in a number of workflows, but have mostly relied on the CLI flags to avoid Yet Another Config File.
With the (hopefully) pending python distributions on #549, more python users will have access to an easy-to-manage version of taplo, which they could include in e.g. [project.optional-depenendencies.lint].
Many python-based tools have centralized on pyproject.toml's reserved, but unconstrained, [tool] section for their configuration. Adopting this convention would improve the overall experience for python projects that might only be using taplofor that file, making an additional top-level .taplo.toml a bit "noisier" than it needs to be.
alternatives
augment the CLI to accept a different top-level table, e.g.
taplo format --config pyproject.toml --config-table tool.taplo pyproject.toml
this... isn't terrible, and would avoid coupling too tightly to a specific ecosystem's conventions, which can always change
By default, every tool looks for one in the working directory or the root of the workspace by the following names (in precedence order):
.taplo.toml
taplo.toml
pyproject.toml under the [tool.taplo] table
a minimal viable pyproject.toml is pretty much what one would expect:
[build-system]
build-backend = "flit_core.buildapi"requires = ["flit_core >=3.7.1,<4"]
[project]
name = "some-neat-project"readme = "README.md"classifiers = ["License :: OSI Approved :: MIT License"]
requires-python = ">=3.9"dynamic = ["version", "description"]
[project.optional-dependencies]
lint = ["taplo", "ruff"]
[tool.ruff]
# ... oh boy it's a lot
[tool.taplo]
include = ["pyproject.toml"]
[[tool.taplo.rule]]
include = ["pyproject.toml"]
keys = ["dependencies", "*-dependencies"]
[tool.taplo.rule.formatting]
reorder_keys = true
getting this into the usual suspects (e.g. schemastore.org) would make it pretty much Just Work for a lot of language server users:
"properties": {
"tool": {
"title": "Tool-specific configuration",
"type": "object",
"description": "A table for tool configurations.\n\nEvery tool that is used by the project can have its own sub-table for its configuration.\n",
"additionalProperties": {
"type": "object"
},
"x-taplo": {
"links": {
"key": "https://www.python.org/dev/peps/pep-0518/#id28"
}
},
"properties": {
"taplo": {
"$ref": "https://json.schemastore.org/taplo.json"
},
And thanks for taplo 🤗 !
The text was updated successfully, but these errors were encountered:
elevator pitch
Enable configuring
taplo
by looking for the well-knownpyproject.toml
file and reading[tool.taplo]
.references
motivation
As a (mostly) python user, I've applied
taplo
(via theconda-forge
redistribution oftaplo-cli
(disclaimer: maintainer) in a number of workflows, but have mostly relied on the CLI flags to avoid Yet Another Config File.With the (hopefully) pending python distributions on #549, more python users will have access to an easy-to-manage version of
taplo
, which they could include in e.g.[project.optional-depenendencies.lint]
.Many python-based tools have centralized on
pyproject.toml
's reserved, but unconstrained,[tool]
section for their configuration. Adopting this convention would improve the overall experience for python projects that might only be usingtaplo
for that file, making an additional top-level.taplo.toml
a bit "noisier" than it needs to be.alternatives
augment the CLI to accept a different top-level table, e.g.
design ideas
the docs might say something like
a minimal viable
pyproject.toml
is pretty much what one would expect:getting this into the usual suspects (e.g. schemastore.org) would make it pretty much Just Work for a lot of language server users:
And thanks for
taplo
🤗 !The text was updated successfully, but these errors were encountered: