-
Notifications
You must be signed in to change notification settings - Fork 294
Drop Google repo–priority in CONTRIBUTING #246
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
Conversation
See google/styleguide#528 (comment). Google is no longer maintaining the public version of cpplint.
CONTRIBUTING.rst
Outdated
The difference between this cpplint and Google should remain so small that anyone can at a glance see there is no added change that could be regarded as a security vulnerability. | ||
* Reducing interference with other popular tools | ||
* Update cpplint for modern python versions | ||
* Converting setup.py to a pyproject.toml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to be careful here - this isnt difficult to do badly, and inviting people to do this will likely result in it being done badly. We want to maintain Python backwards compatibility as much as possible because people using cpplint are likely to be using much older versions of Windows/Linux for their build environment because they have some third-party SDK that isnt available on newer OS versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK pyproject.toml is compatible with 3.6.
How about
* Converting setup.py to a pyproject.toml | |
* Converting setup.py to a pyproject.toml | |
* Preserve backwards-compatibility without sacrificing readability |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My point is this document is not the place to ask for someone to do "Converting setup.py to a pyproject.toml".
An issue should be created about this enhancement, and the needs to be done carefully according to that issue, probably by one of the maintainers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how to incorporate "improve compatibility" now. It's not something we can just create an issue about, yet it's also a goal, and making it the only goal would look weird. "Add features and provide a PyPI package" seems like a given for almost any Python project.
@@ -65,7 +63,7 @@ The modifications in this fork are minor fixes and cosmetic changes, such as: | |||
* JUnit XML output format | |||
* Overriding repository root auto-detection via --repository | |||
* Support ``#pragma once`` as an alternative to header include guards | |||
* ... and a few more (most of which are open PRs on upstream) | |||
* ... and `quite a bit <https://github.com/cpplint/cpplint/blob/master/changelog.rst>`_ more |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should point to the develop
branch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we change the branches to the same one, I feel like we should name that branch master. Plus, we'd merge all released changes in develop to master anyway.
See google/styleguide#528 (comment). Google is no longer maintaining the public version of cpplint, and pretty much everything in their repo's PRs and issues about cpplint have gone unimplemented. Thus, recommending people do stuff there first is sort of useless, and there's not much use confining ourselves to Google's feature set.
I have replaced it with something that's sort of a to-do list + a list of things that probably shouldn't be done.
This may not be needed if the promised publishing of Google's internal version arrives.
Note that I didn't mean to say "Google-favoring" in a derogatory way. Better wording suggestions are welcome.
(When merging, please squash and merge)