Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add endLine and endColumn keys to JSONReporter #5456

Merged
merged 2 commits into from Dec 3, 2021

Conversation

cdce8p
Copy link
Member

@cdce8p cdce8p commented Dec 2, 2021

Type of Changes

Type
✨ New feature

Description

Based on the work of @DanielNoord in 6e91225, I've added the endLine and endColumn keys to the output of the JSONReporter. These are necessary for support in vscode-python.

I've explicitly chosen endLine (not end_line) and endColumn as those are better compatible with javascript syntax.

Closes #5380

Co-authored-by: Daniël van Noord <13665637+DanielNoord@users.noreply.github.com>
@cdce8p cdce8p added this to the 2.12.2 milestone Dec 2, 2021
@cdce8p cdce8p added the Enhancement ✨ Improvement to a component label Dec 2, 2021
@coveralls
Copy link

coveralls commented Dec 2, 2021

Pull Request Test Coverage Report for Build 1535142075

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 93.538%

Totals Coverage Status
Change from base Build 1535104011: 0.0%
Covered Lines: 14026
Relevant Lines: 14995

💛 - Coveralls

Copy link
Member

@Pierre-Sassoulas Pierre-Sassoulas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, isn't it a small breaking change dependending on the way the json is read ? Thinking about Message(**json.load(..)) here. Regarding breaking change we may as well do them properly in a major, where they are expected instead of multiple small one released with minors where they are not ? We already had multiple downstream bug following breaking change in things we considered internal. We don't want downstream libs to not have enough trust to recover our minors automatically right ?

@cdce8p
Copy link
Member Author

cdce8p commented Dec 3, 2021

Looks good, isn't it a small breaking change depending on the way the json is read ?

In theory, it could be. The problem is that we need this change for error range support in vscode-python. At least I've not been able to come up with an alternative implementation that's also backwards compatible.

With the json output, it a) only effects a limited audience to begin with, b) should, for the most part, be backwards compatible with existing use cases, and c) if it does break, users should be able to work around it.

I'm open to suggestions, if anyone has a better idea.

--
Usually I too would prefer such changes in a major version (eg. 3.0), I just don't think that makes much sense here. Neither does waiting until we are ready for it as the vscode-python PR is currently blocked. It isn't ideal, but thats the unfortunate tradeoff for working with an old codebase.

Copy link
Member

@Pierre-Sassoulas Pierre-Sassoulas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's make the tradeoff then, having range in vscode now as opposed to when 3.0 is released months or years is a powerful motivator.

@Pierre-Sassoulas Pierre-Sassoulas merged commit 765a0b7 into pylint-dev:main Dec 3, 2021
@cdce8p cdce8p deleted the feature_json-endLine branch December 3, 2021 14:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement ✨ Improvement to a component
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add end_line and end_column to the output of the JSONReporter
3 participants