-
-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
python@3.10 3.10.7 #109777
python@3.10 3.10.7 #109777
Conversation
41e2df7
to
fad8131
Compare
fad8131
to
5dc3166
Compare
This should be done in the next hour or so. |
Fix for speedtest-cli: #110021 |
Looks like
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. To keep this pull request open, add a |
It would be good to rebase and re-run this. Not sure there's enough time for that before tomorrow's maintenance window though. |
5dc3166
to
8d0ee64
Compare
The poetry error is not fixed, maybe keyring is still need to be disabled. I wonder why the poetry tests only fail in this pull request. |
If we disable keyring in the test, does that mean users need to disable it on their own to use If so, then that's not a good solution, because we are then shipping something effectively broken. |
The test failed because Keychain can't be unlocked in CI, normal user probably won't encounter this error. But these test commands shouldn't need to find password in Keychain. |
This was always the case, though. Why didn't it fail previously, and why is it failing now with this version of Python? |
Maybe because it's a new feature: python-poetry/poetry#1917 (comment) I don't know why poetry wants to use keyring in this case but other people in that issue solved this error by disabling keyring. |
But the feature seems to be there already, but the failure appears to be triggered only by Python 3.10.7 and not Python 3.10.6. So I don't think the feature being new is enough of an explanation. Hey @neersighted, apologies for the tag but we could use your expertise here. Does it make sense to disable This makes sense to do if the |
Hi @carlocab -- keyring usage in Poetry is new, and the matrix of possible OS versions/keyring backends/local system configration is vast and well beyond the ability of any project to test. It's been pretty clear since this feature has made it out into the wild that Poetry needs more robust error handling/usage of keyring. There should be improvements to keyring usage coming to future releases (including patch releases) of Poetry, but in the here and now, keyring should not be something you need in CI and can be safely disabled. It is a very desirable feature for end users (e.g. on macOS, storing credentials in the keychain instead of plaintext on disk), as PyPI credentials are incredibly valuable as supply chain attacks can be conducted using them. I would suggest keeping an eye on the Poetry changelog for improvements to our handling of these errors, and in the mean time just setting the env var (or using the config file as described in python-poetry/poetry#1917) to disable keyring in CI. |
Let's disable the test then: #111744 |
Fix for audio: #111745 |
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've seen the macOS failures elsewhere so they're pre-existing. Having python3
built against gcc-5
is also causing failures elsewhere on Linux, so let's merge this.
We probably want to set CC=cc
on Linux or something to avoid hardcoding the GCC version.
Let's check that this is working fine after Homebrew#109777.
Created with
brew bump-formula-pr
.resource
blocks may require updates.