Any interest in trying to develop a standardized, programmatic API for linters?
As the dev manager for the Python extension for VS Code, one of the things my team supports is linter support. When someone comes and asks us to support a linter we have to consider a couple of things:
1. Is the linter popular enough to warrant the overhead of adding support? 2. How old/stable is the linter's stdout output for parsing? 3. Has anyone already written the regex to parse the output? đ
And I think every other editor out there that supports Python linters go through the same thing in some form or another. I would like to do away with having to make these calls. âş
Would there be interest from the PyCQA to work towards a programmatic API in Python that linters could implement which editors like VS Code could use so that supporting a linter takes as little effort as possible? It could even potentially be registered as an entry point, making linter discovery automatic for editors. Even bigger thinking is getting this all behind a united project which supports LSP (language server protocol), so editors can just plug that project in and get Python linter support for free.
For you linter maintainers, the wins that come to mind for me is getting into editors more easily and making sure we don't mess it up. đ I wouldn't have to turn people down for supporting a linter ever again and you all wouldn't have to worry about me and my team botching our support somehow because we messed up our regex in parsing your output.
I started this discussion with other editor/IDE maintainers at https://discuss.python.org/t/any-interest-in-working-out-a-standard-api-for-.... I have a draft of an API at https://discuss.python.org/t/any-interest-in-working-out-a-standard-api-for-... to help make this more concrete idea to talk about.
If this sounds like an idea this group could support, I would be up for writing a PEP and obviously supporting this in the Python extension for VS Code.
So I think this is a good idea. I think it'd be even better if it it helped standardize things outside of the LSP users area too, namely I'm thinking about tools like CodeClimate that require a specific output format, etc.
On Thu, Jan 7, 2021 at 5:33 PM Brett Cannon brett@python.org wrote:
As the dev manager for the Python extension for VS Code, one of the things my team supports is linter support. When someone comes and asks us to support a linter we have to consider a couple of things:
- Is the linter popular enough to warrant the overhead of adding support?
- How old/stable is the linter's stdout output for parsing?
- Has anyone already written the regex to parse the output? đ
And I think every other editor out there that supports Python linters go through the same thing in some form or another. I would like to do away with having to make these calls. âş
Would there be interest from the PyCQA to work towards a programmatic API in Python that linters could implement which editors like VS Code could use so that supporting a linter takes as little effort as possible? It could even potentially be registered as an entry point, making linter discovery automatic for editors. Even bigger thinking is getting this all behind a united project which supports LSP (language server protocol), so editors can just plug that project in and get Python linter support for free.
For you linter maintainers, the wins that come to mind for me is getting into editors more easily and making sure we don't mess it up. đ I wouldn't have to turn people down for supporting a linter ever again and you all wouldn't have to worry about me and my team botching our support somehow because we messed up our regex in parsing your output.
I started this discussion with other editor/IDE maintainers at https://discuss.python.org/t/any-interest-in-working-out-a-standard-api-for-.... I have a draft of an API at https://discuss.python.org/t/any-interest-in-working-out-a-standard-api-for-... to help make this more concrete idea to talk about.
If this sounds like an idea this group could support, I would be up for writing a PEP and obviously supporting this in the Python extension for VS Code. _______________________________________________ code-quality mailing list -- code-quality@python.org To unsubscribe send an email to code-quality-leave@python.org https://mail.python.org/mailman3/lists/code-quality.python.org/ Member address: graffatcolmingov@gmail.com
There is already SARIF (http://sarifweb.azurewebsites.net/) but I don't think it's been adopted by anything. I like the idea though. On 08/01/2021 00:44:10, Ian Stapleton Cordasco graffatcolmingov@gmail.com wrote: _______________________________________________ code-quality mailing list -- code-quality@python.org To unsubscribe send an email to code-quality-leave@python.org https://mail.python.org/mailman3/lists/code-quality.python.org/ Member address: carl.crowder@gmail.com So I think this is a good idea. I think it'd be even better if it it helped standardize things outside of the LSP users area too, namely I'm thinking about tools like CodeClimate that require a specific output format, etc.
On Thu, Jan 7, 2021 at 5:33 PM Brett Cannon <brett@python.org [mailto:brett@python.org]> wrote:
As the dev manager for the Python extension for VS Code, one of the things my team supports is linter support. When someone comes and asks us to support a linter we have to consider a couple of things:
1. Is the linter popular enough to warrant the overhead of adding support? 2. How old/stable is the linter's stdout output for parsing? 3. Has anyone already written the regex to parse the output? đ
And I think every other editor out there that supports Python linters go through the same thing in some form or another. I would like to do away with having to make these calls. âş
Would there be interest from the PyCQA to work towards a programmatic API in Python that linters could implement which editors like VS Code could use so that supporting a linter takes as little effort as possible? It could even potentially be registered as an entry point, making linter discovery automatic for editors. Even bigger thinking is getting this all behind a united project which supports LSP (language server protocol), so editors can just plug that project in and get Python linter support for free.
For you linter maintainers, the wins that come to mind for me is getting into editors more easily and making sure we don't mess it up. đ I wouldn't have to turn people down for supporting a linter ever again and you all wouldn't have to worry about me and my team botching our support somehow because we messed up our regex in parsing your output.
I started this discussion with other editor/IDE maintainers at https://discuss.python.org/t/any-interest-in-working-out-a-standard-api-for-... [https://discuss.python.org/t/any-interest-in-working-out-a-standard-api-for-...]. I have a draft of an API at https://discuss.python.org/t/any-interest-in-working-out-a-standard-api-for-... [https://discuss.python.org/t/any-interest-in-working-out-a-standard-api-for-...] to help make this more concrete idea to talk about.
If this sounds like an idea this group could support, I would be up for writing a PEP and obviously supporting this in the Python extension for VS Code. _______________________________________________ code-quality mailing list -- code-quality@python.org [mailto:code-quality@python.org] To unsubscribe send an email to code-quality-leave@python.org [mailto:code-quality-leave@python.org] https://mail.python.org/mailman3/lists/code-quality.python.org/ [https://mail.python.org/mailman3/lists/code-quality.python.org/] Member address: graffatcolmingov@gmail.com [mailto:graffatcolmingov@gmail.com]
Carl Crowder wrote:
There is already SARIF (http://sarifweb.azurewebsites.net/) but I don't think it's been adopted by anything.
I think I checked and no one was supporting it yet in the Python community.
I like the idea though.
So would SARIF -- which was also brought up in the discussion with the editor maintainers -- be the expected return value of the function call as a JSON object?
On 08/01/2021 00:44:10, Ian Stapleton Cordasco graffatcolmingov@gmail.com wrote: _______________________________________________ code-quality mailing list -- code-quality@python.org To unsubscribe send an email to code-quality-leave@python.org https://mail.python.org/mailman3/lists/code-quality.python.org/ Member address: carl.crowder@gmail.com So I think this is a good idea. I think it'd be even better if it it helped standardize things outside of the LSP users area too, namely I'm thinking about tools like CodeClimate that require a specific output format, etc.
For me, LSP is a potential long-term thing and definitely not a driving motivator or v1 goal for this; I agree that the key motivator is coming up with something that simply opens the doors to more people to integrate Python linters.
-Brett
On Thu, Jan 7, 2021 at 5:33 PM Brett Cannon <brett@python.org [mailto:brett@python.org]> wrote: As the dev manager for the Python extension for VS Code, one of the things my team supports is linter support. When someone comes and asks us to support a linter we have to consider a couple of things:
Is the linter popular enough to warrant the overhead of adding support? How old/stable is the linter's stdout output for parsing? Has anyone already written the regex to parse the output? đ
And I think every other editor out there that supports Python linters go through the same thing in some form or another. I would like to do away with having to make these calls. âş Would there be interest from the PyCQA to work towards a programmatic API in Python that linters could implement which editors like VS Code could use so that supporting a linter takes as little effort as possible? It could even potentially be registered as an entry point, making linter discovery automatic for editors. Even bigger thinking is getting this all behind a united project which supports LSP (language server protocol), so editors can just plug that project in and get Python linter support for free. For you linter maintainers, the wins that come to mind for me is getting into editors more easily and making sure we don't mess it up. đ I wouldn't have to turn people down for supporting a linter ever again and you all wouldn't have to worry about me and my team botching our support somehow because we messed up our regex in parsing your output. I started this discussion with other editor/IDE maintainers at https://discuss.python.org/t/any-interest-in-working-out-a-standard-api-for-... [https://discuss.python.org/t/any-interest-in-working-out-a-standard-api-for-...]. I have a draft of an API at https://discuss.python.org/t/any-interest-in-working-out-a-standard-api-for-... [https://discuss.python.org/t/any-interest-in-working-out-a-standard-api-for-...] to help make this more concrete idea to talk about. If this sounds like an idea this group could support, I would be up for writing a PEP and obviously supporting this in the Python extension for VS Code.
code-quality mailing list -- code-quality@python.org [mailto:code-quality@python.org] To unsubscribe send an email to code-quality-leave@python.org [mailto:code-quality-leave@python.org] https://mail.python.org/mailman3/lists/code-quality.python.org/ [https://mail.python.org/mailman3/lists/code-quality.python.org/] Member address: graffatcolmingov@gmail.com [mailto:graffatcolmingov@gmail.com]
participants (3)
-
Brett Cannon -
Carl Crowder -
Ian Stapleton Cordasco