-
Notifications
You must be signed in to change notification settings - Fork 7
How will we update pylint? #2
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
Comments
I think the idea was to just have one place to do it rather than dig into lots of repos. Why do you think it needs to be done piecemeal? |
If the individual repos require changes from switch from 1 to 2 then you won't be able to it. If the changes for are backwards compatible you can do it but then it isn't enforced until this version is flipped. |
I think if we need any to stay on an older version, we could set an environment variable in the Github Actions workflow for that page and add a check in this script. |
This is a good discussion point. My half-considered medium term plans for actions on the libs is to add some hooks to the workflow to allow libs to override the defaults. I'm going to think deeper about this when I work on my CP 2020 post tonight |
Sounds good! Thank you both. |
Any more thoughts? I don't think pylint 1.9.2 works on Python 3.7 so I'd like us to start using newer pylint soon. |
I haven't had any more substantial thoughts on this directly but moving to pylint 2.x is high on @dherrada 's list, I believe just after a super secret project that he hasn't been told about yet. This will have to be solved as part of that. I'll try and nail down some specifics with @sommersoft before we get to that point |
No more thoughts on this from me either. I still think adding the ability to set something in the Github Actions workflow to a specific version of pylint to override the default is the right approach and then just set the default here. |
Ok, perfect. We'll likely want a way to move individual repos at a time. I'm pretty sure I've found a pylint bug so making it easy for us to update would be great. That way I can fix it upstream and then update. :-) Thanks! |
FYI - on my Raspberry Pi -- I have updated Pylint and it still seems to be working OK with the library I am working on (RFM9x) |
@siddacious 🕵️♂️ |
Ok, I did have some more thoughts on this. I usually run a newer version of pylint locally and I usually have to ignore some of the checks that are failing because they don't fail when uploaded. This means that if we update to a newer version, some repos that were previously passing may fail and it may mean updating the .pylintrc file on those to ignore checks that we aren't concerned about. The cookie cutter will probably need to be updated soon too. This is good in the long run because it will show more consistently between running locally and remotely, but may be a bit annoying until we get there in the short-term. |
@kattni and I had a small discussion concerning this, and I know that there are internal discussions on-going. But, I wanted to offer an approach that I came up with.
Butcher this idea at will. It was kind of off-the-cuff, and as I'm wont to do, it focuses on Adabot a lot. 😄 🤖 |
I like it. Having adabot doing all the work makes it an easy implementation. :) |
Sounds good to me!
…On Thu, Feb 13, 2020 at 7:16 PM Melissa LeBlanc-Williams < ***@***.***> wrote:
I like it. Having adabot doing all the work makes it an easy
implementation. :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2?email_source=notifications&email_token=AAJBB4MIVQ2QQQZQ7BTLWXTRCYEIDA5CNFSM4KEBNX3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELXNQMA#issuecomment-586078256>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJBB4MIBFZRNWSVLAECIHLRCYEIDANCNFSM4KEBNX3A>
.
|
@sommersoft I like that idea! What about only including the major version such as 1 or 2? I don't think we need to peg exact version. |
I actually didn't know if pip supported this. Looks like it its possible. Easiest seems to be
With regard to only pinning to major versions, I will note that reading through pylint's changelog they do add new checks in minor versions. |
I've done |
After more thought on this, could we just move the pylint, black and sphinx installs back into build.yaml? Having them hidden behind install.sh makes it non-obvious what install locally when fixing an issue. It's a very simple way to solve the versioning issue as well. |
I agree with moving back to I also agree that pinning it to anything may not make sense as new checks are added with minor releases. Regardless, this will force us to keep up with updating our code on a more regular basis versus this sort of major push again after avoiding it for too long. Please move the Pylint, Black, and Sphinx installs back into the |
Ok. New plan of attack:
Once draft is approved:
|
@sommersoft Step 1 complete and approved. Let's move on to the next steps. Thanks! |
Patches applied. Results:
I'll handle the 8 skips/failures manually (if necessary). |
@sommersoft Thank you! |
No need to address:
The repo has been archived. 😄 |
Once I patch these last 9 repos, I'll close this... Excellent work, communication, and perseverance to everyone!! |
I like that this is centralized but would like us to update pylint at some point. How can we do that piecemeal when the install for it is here?
No rush, just something to consider.
The text was updated successfully, but these errors were encountered: