SyntaxError is unable to return code on Linux

[WutingjiaX]

"SyntaxError", ""code": null", "linux", "Debian"

I run the same code on MacOS and Linux(Debian GNU/Linux 10 (buster)), with the cmd:

ruff check --output-format=json test.py

ruff version 0.5.1

The code in the test.py is any Python code that may cause syntax errors， such as：

import .

the output on linux is:

[
  {
    "cell": null,
    "code": null,
    "end_location": {
      "column": 9,
      "row": 1
    },
    "filename": "/home/code/test.py",
    "fix": null,
    "location": {
      "column": 8,
      "row": 1
    },
    "message": "SyntaxError: Expected an import name",
    "noqa_row": null,
    "url": null
  },
  {
    "cell": null,
    "code": null,
    "end_location": {
      "column": 1,
      "row": 2
    },
    "filename": "/home/code/test.py",
    "fix": null,
    "location": {
      "column": 9,
      "row": 1
    },
    "message": "SyntaxError: Expected one or more symbol names after import",
    "noqa_row": null,
    "url": null
  }
]

but on MacOS,the output is:

[
  {
    "cell": null,
    "code": "E999",
    "end_location": {
      "column": 9,
      "row": 1
    },
    "filename": "/Users/bytedance/Library/Application Support/JetBrains/PyCharm2023.3/light-edit/test.py",
    "fix": null,
    "location": {
      "column": 8,
      "row": 1
    },
    "message": "SyntaxError: Expected an import name",
    "noqa_row": 1,
    "url": "https://docs.astral.sh/ruff/rules/syntax-error"
  }
]%

I can't understand why the output is different (especially if one code field has a value and the other doesn't)

[MichaReiser]

I suspect that you're using two different Ruff versions. Can you try running ruff --version on both systems and verify that they're the same?

[WutingjiaX]

I suspect that you're using two different Ruff versions. Can you try running ruff --version on both systems and verify that they're the same?

@MichaReiser oh！you're right，my local version on MacOS is 0.4.9 （though I have the same pyproject.toml）， But why is it that there is no code in higher versions instead

[MichaReiser]

This has been changed as part of 0.5. For more details, see the announcement blog post. Do you have a specific use for the error code?

[WutingjiaX]

@MichaReiser
Thank you for your answer！If the code can be null, it needs some consideration when deserializing (such as using pydantic,it should be optional instead of string). But this is not a big problem

[dhruvmanila]

@MichaReiser Thank you for your answer！If the code can be null, it needs some consideration when deserializing (such as using pydantic,it should be optional instead of string). But this is not a big problem

Yeah, I think I should've added something around the fact that the type of cell and noqa_row is now string | null in the output formats. Sorry for the confusion!

[kaste]

This change breaks the Sublime Text plugin which assumed "code: str". kaste/SublimeLinter-contrib-ruff#2

This is easy to fix and I have to anyway but in Sublime Text the "rule name" aka "code" actually matters as the "diagnostics" can be styled per linter name, per error-type ("severity"), and per rule-name. E.g. I literally use a bomb icon for E999 errors.

(Why is that an Optional[str] anyway. If I do item["code"], I ask what the code is and since there is a key, you basically answer: Yeah sure I have the code, it's ... a nah ... don't know.)

[dhruvmanila]

(Why is that an Optional[str] anyway. If I do item["code"], I ask what the code is and since there is a key, you basically answer: Yeah sure I have the code, it's ... a nah ... don't know.)

You can find some context in the blog post and some discussion in the original PR but the tldr is that the rule itself is deprecated i.e., E999 doesn't exists in Ruff anymore. This means we can't use the code anywhere. Syntax errors are now always shown and one cannot select / ignore them. Regarding the type, it's Optional[str] because it's the value that's optional and not the key itself. The key will always be present but as there's no rule code for a syntax error, it will be null instead.