Thanks for starting on this! There are many more errors Keyring has been throwing (one of the reasons no one has started on this yet) -- see all the dupes of #1917 for situations we should handle.

We also most definitely need a unit/regression test for this.

When will this be merged? We get this a lot on our enterprise HPC at work and have to run a workaround environment variable all the time.

Thanks for starting on this! There are many more errors Keyring has been throwing (one of the reasons no one has started on this yet) -- see all the dupes of #1917 for situations we should handle.

I was looking through all linked issues for Exceptions poetry could catch to prevent this. I bumped into some problems. Sometimes the keyring raises a RuntimeError. I guess discarding that isn't a problem. However how to catch win32ctypes.pywin32.pywintypes.error which is a direct subclass of Exception?
There even was an incident where keyring raised a ModuleNotFoundError. IMO the last two are issues of keyring and should be handled by that library. However we could also simply catch all Exceptions.

I would agree with you: catching keyring.errors.KeyringError seems like the right thing to do, and if keyring raises other errors then that feels to me like a bug that should be raised against that project.

That ought to catch the great majority of cases; and if keyring does take the view that it can raise any old exception and callers are supposed to handle them all - well that will be a simple enough thing to change later.

Ok, so I opened an updated PR: #8227

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.