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

PyLint install fails during Code Style check #3408

Closed
pljones opened this issue Oct 12, 2024 · 10 comments
Closed

PyLint install fails during Code Style check #3408

pljones opened this issue Oct 12, 2024 · 10 comments
Labels
bug Something isn't working tooling Changes to the automated build system

Comments

@pljones
Copy link
Collaborator

pljones commented Oct 12, 2024

Describe the bug

Running pip install --user "pylint < 3.0" fails with an error, causing the overall build to fail with a code style error.

To Reproduce

Raise a PR or run a the "Verify Python coding style" work flow (without --break-system-packages)

Expected behavior

pylint should be install and the check should run successfully (assuming not breakage in python code style).

Additional context

Raised on Discord (note, all old builds now gone):

[ 16:19 ] pljones:
Anyone know why the python check fails?
https://github.com/jamulussoftware/jamulus/actions/runs/11306641904/job/31447466526?pr=3394
[ 16:20 ] dtinth:
recently-updated gh actions image breaks pip. just add --break-system-packages to the command should fix it.
example dtinth/jamulus-php@be02a7c
[ 16:24 ] pljones:
So patch main with that, then revert?
[ 17:13 ] pljones:
Just patch for now. Is "pylint < 3.0" available on ubuntu-latest? My 24.04 LTS has only 3.0.3 available for apt; maybe it could use pipx rather than --break-system-packages?

$ apt list pylint
Listing... Done
pylint/noble,noble 3.0.3-2 all
@pljones pljones added the bug Something isn't working label Oct 12, 2024
@github-project-automation github-project-automation bot moved this to Triage in Tracking Oct 12, 2024
@pljones pljones added this to the Release 3.12.0 milestone Oct 12, 2024
@pljones pljones added the tooling Changes to the automated build system label Oct 12, 2024
@pljones pljones moved this from Triage to Backlog in Tracking Oct 12, 2024
@ann0see
Copy link
Member

ann0see commented Oct 19, 2024

@pljones the fixes on main don't seem to fix the issue.

@pljones
Copy link
Collaborator Author

pljones commented Oct 20, 2024

What do you mean? Currently the build on main runs. Without the workaround, it didn't run. So the workaround on main is still there. The issue is that it's a work around and not a fix. Someone needs to work out what the fix is and implement it to close this issue.

@ann0see
Copy link
Member

ann0see commented Oct 20, 2024

I meant that https://github.com/jamulussoftware/jamulus/actions/runs/11386428899/job/31678620735#step:3:1 shows that the coding style check does not run.

@pljones
Copy link
Collaborator Author

pljones commented Oct 21, 2024

Um, interesting... I wonder what changed.

@pljones
Copy link
Collaborator Author

pljones commented Oct 21, 2024

https://github.com/jamulussoftware/jamulus/actions/runs/11367998339/job/31622018160#step:3:2 ran okay...

https://github.com/jamulussoftware/jamulus/actions/workflows/coding-style-check.yml
In fact, up until your last couple of builds, it looks to have been okay. I can only guess the action is using something that's not properly pinned.

Which, again, is why there's an issue with that action.

@softins
Copy link
Member

softins commented Oct 24, 2024

The addition of --break-system-packages has been consistently failing, presumably due to the version of pip not recognising it.

So I reverted the relevant commit c1718a8 in a test branch and ran the action. It succeeded, so I wonder if the original problem that prompted this Issue to be raised has now gone away?

@pljones
Copy link
Collaborator Author

pljones commented Oct 24, 2024

I don't like it being unstable... I thought we generally pinned versions of the actions to avoid things like this? Or is it not the action itself?

@softins
Copy link
Member

softins commented Oct 25, 2024

I don't see how it could be due to an external action, such as actions/checkout@v4. Our own job runs pip to obtain pylint, and it would appear that the version of pip that comes in the ubuntu-latest runner doesn't understand --break-system-packages, but also without that switch it does now correctly install pylint < 3.0.

I'm wondering if the original problem was a temporary glitch in the Python repositories with a broken dependency or something?

I would recommend taking the --break-system-packages out again, and then waiting until the original problem recurs, if indeed it does.

@pljones
Copy link
Collaborator Author

pljones commented Oct 25, 2024

#3415 raised to try the revert.
https://github.com/jamulussoftware/jamulus/actions/runs/11521963146 manually run for revert.

@ann0see ann0see closed this as completed Oct 31, 2024
@github-project-automation github-project-automation bot moved this from Backlog to Done in Tracking Oct 31, 2024
@ann0see
Copy link
Member

ann0see commented Oct 31, 2024

I believe this is fixed. Otherwise please re open

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working tooling Changes to the automated build system
Projects
Status: Done
Development

No branches or pull requests

3 participants