Unable to parse '.ruff.toml' when configured for Ruff linter

[echoix]

Describe the bug
A clear and concise description of what the bug is.

I configured '.ruff.toml' with additional parameters for Ruff linter, and when running locally or GHA I encounter parsing error:

--Error detail:
<jemalloc>: MADV_DONTNEED does not work (memset will be used instead)
<jemalloc>: (This is the expected behaviour if you are running under QEMU)
ruff failed
  Cause: Failed to parse `/tmp/lint/.ruff.toml`: TOML parse error at line 1, column 1
  |
1 | [format]
  | ^^^^^^^^
wanted exactly 1 element, more than 1 element

To Reproduce
Steps to reproduce the behavior:

1. enable Ruff linter and Create .ruff.toml
2. Provide the following parameters in .ruff.toml:

[format]
indent-style = "tab"
quote-style = "single"

4. Run locally 'mega-linter-runner --flavor python' (or) via GH Actions.
5. See error:

--Error detail:
<jemalloc>: MADV_DONTNEED does not work (memset will be used instead)
<jemalloc>: (This is the expected behaviour if you are running under QEMU)
ruff failed
  Cause: Failed to parse `/tmp/lint/.ruff.toml`: TOML parse error at line 1, column 1
  |
1 | [format]
  | ^^^^^^^^
wanted exactly 1 element, more than 1 element

Expected behavior
Script expected to be tab indented and quote style be single quote.

Screenshots
N/A

Additional context
When running Ruff as-is it works well with:

ruff format "myScript.py"

Megalinter's ruff ver :

 "ruff": "0.0.291",

My local Stand-alone Ruff ver: ruff 0.0.291

Python flavor: oxsecurity/megalinter/flavors/[email protected]

Originally posted by @fawazsalah in oxsecurity/megalinter#2995

---

And with a comment that has the same bug directly with ruff:

Since the error occurs when running Ruff through MegaLinter but not when running Ruff directly, and MegaLinter v7.4.0 is on Ruff 0.0.290, I would try running Ruff directly at 0.0.290.

Thanks @Kurt-von-Laven and @echoix for the support.

Bingo Good catch; I can confirm similar error with 0.0.290 locally.

[...]

Originally posted by @fawazsalah in oxsecurity/megalinter#2995 (comment)

[charliermarsh]

Hmm, I'm unable to reproduce this on Ruff v0.0.291 or v0.0.292.

With:

❯ ruff --version
ruff 0.0.291

I created foo.py with x=1, and ruff.toml with:

[format]
indent-style = "tab"
quote-style = "single"

Running ruff format foo.py:

warning: `ruff format` is a work-in-progress, subject to change at any time, and intended only for experimentation.
1 file reformatted

[charliermarsh]

Let me verify that the config is being picked up in my repro.

[charliermarsh]

Hmm, yes, confirmed, so still unable to repro. Could megalinter be using an older version?

[echoix]

If the whole parsing of the format section in a ruff.toml file instead of a pyproject.toml file isn't broken, I suspect something with a BOM header might be going on here.

Does your tests cover a similar case?

[echoix]

The affected version was 0.290 (from that user).

[echoix]

Hmm, yes, confirmed, so still unable to repro. Could megalinter be using an older version?

The latest release of Megalinter still has 0.290, but 0.291 is already in main.

0.292 is still in oxsecurity/megalinter#2988

[zanieb]

The new format section is only available in 0.0.291+ (#7543); related #7514

[echoix]

I saw the second, #7514, but thought that an existing cli option was renamed, but didn't realise by the release notes that it didn't exist yet, as I thought it was a rename of an old command, and output-format wasn't at a section level.

So I'll go and mention that. I really didn't catch that it was a new feature from the release notes, I caught that lint was a new section though.
Some projects, like the Python documentation, or CMake documentation add at what version a feature was added. Is it something that would be worth it for your project? (I see it is very fast-moving, congratulations for your work!)

[Kurt-von-Laven]

I have often spent significant time determining which rules are available at which version. Sometimes I have found the answer in the release notes, and sometimes have resorted to binary search.

[zanieb]

So... we took the format = <string> option and renamed it to output-format = <string> (with backwards compatibility) to make room for the [format] section which can be used for our formatter options. Since you were using [format] with an older version that expected a string you were getting the error message "wanted exactly 1 element, more than 1 element".

I'd like to have documentation include versions in which things are added. We'd need to build out tooling for it though.

[Kurt-von-Laven]

Sphinx offers ::versionadded::. Sphinx, Docusaurus, and MkDocs offer versioning.

[zanieb]

Unfortunately I don't think those really address our use-cases. We'd probably need to build the tooling into our Rust documentation generator, but we should talk about this in a new discussion instead of cluttering this issue.