I’ve been looking everywhere as to whether SonarQube can ‘read’ mypy reports (which can be outputted in a variety of formats including JUnit and Cobertura). While I can see that the feature of ingesting external reports e.g., bandit the Pythonic security scanner, is implemented I cannot find anything on mypy which provides a lot of info on type-violations and would be fantastic to have it appear as comments on a PR.
Do you know if that is at all possible and if not whether there’s plans to include it in an upcoming release?
This feature doesn’t exist yet. Thank you for suggesting it.
We are currently planning some big efforts on SonarPython and type-checking could definitely be a part of it. There are different ways we could do it: support mypy, pyre, pytype or have a good type checker built-in. However we have a few more steps in our current roadmap before we reach this point, so I can’t promise anything yet.
Given the number of different external inspection utilities it would be ideal if SQ could integrate their reports in the code analysis, I can only assume that’d be less work than making your own type-checker.
Is the roadmap public? Could you share some link if it is?
Yes integrating existing tools makes sense. However we need to first investigate what is possible. Integrating the wrong tool could conflict with some of our priorities:
SonarQube/SonarCloud user experience should be good out of the box, even when third party tools are not enabled. Thus if we value type-checking, it should be present even when people don’t use mypy. It doesn’t mean that we wouldn’t use an existing library for type-checking.
We want to raise as little false positives as possible, otherwise developers end up ignoring every issue. Some tools prefer to not miss any potential issue even if it means raising many false positives. I can’t juge yet if it is the case of mypy.
Our current efforts on Python are described in this ticket: https://jira.sonarsource.com/browse/MMF-1712. Not every sub-ticket is specified yet but you can already see the main steps.
@Nicolas_Harraudeau thanks for that it was really interesting to see that you guys are putting emphasis on Python, clearly I’m biased but I think it’s a wise move , not only cause as a language it has won the data-science wars (ML and AI are synonymous with Python these days) but because it’s often over-dynamic traits necessitate a tool like SonarQube when it comes to working within a large team where flame-wars regarding best-practices are often an issue.
With the advent of Python 3 and the EOL for Python 2 even big corporate teams are porting over and tools like mypy and black are now becoming widely used and nearly standard so it’d be ideal if these ‘best practices’ as adopted by FOSS community get reflected in SQ.
Overall I’m very excited to see SQ give Python some more love, hope to see new releases soon!
, not only cause as a language it has won the data-science wars (ML and AI are synonymous with Python these days) but because it’s often over-dynamic traits necessitate a tool like SonarQube when it comes to working within a large team where flame-wars regarding best-practices are often an issue.