docs/Makefile: work around python-poetry issue #8761 #1259
Conversation
Python-poetry is affected by bug <python-poetry/poetry#8761>. Namely, if you have "keyring" <https://pypi.org/project/keyring/> installed, poetry will try to gain access to the Default collection in the (ex. GNOME) keyring, even if poetry only needs read-only access to package repositories, and even if those repos are public. Consequently, you either unlock your Default collection for poetry (unjustifiedly), or your GUI session gets effectively locked up, because any time you hit Cancel on the keyring unlock dialog, poetry immediately pops up another, and this dialog grabs the keyboard -- you cannot even switch to a character VT, for killing poetry; you have to log in via ssh for that. This issue is not visible to users who don't use "keyring" (GNOME or otherwise). For those who do, work around the problem by selecting the "null" keyring back-end, in the environment of every poetry invocation. Note: I have not regression-tested the workaround in a desktop environment where "keyring" is unavailable to begin with. Signed-off-by: Laszlo Ersek <[email protected]>
|
@annastuchlik can you please review this? Thank you. |
I need to defer to @dgarcia360. Thanks! |
|
@dgarcia360 can you please comment? Thanks. |
|
OK, due to zero reviewer feedback, I'm abandoning this one. No need to clog my queue (or this issue tracker) with items that noone cares about. |
Given all other technical aspects of the Sphinx theme, we need to verify whether this PR can be merged or if we should simply document this particular case. That's why I'm reopening this PR. The doc team has one member, and the Sphinx team has 0,4 members. We have other tasks prioritized, and the queue is long. If you don't want to track this PR, then don't. We'll take care of it once we allocate time to work on it. |
OK, that's doable; thanks. In general, I don't drop an item from my personal todo list until/unless it is resolved (one way or another) in its respective primary tracker. When a PR or ticket gets in such a state, it has arguably (and generally) fallen through the cracks. However, if you prefer keeping things open even if the queue gets long, I'm happy to follow your guidance. |
|
@lersek Thank you for reporting this, and apologies for the delayed response. We had other priorities and wanted to allocate time to fully understand and test this issue. It appears this may be resolved in the upcoming Poetry release that introduces breaking changes: python-poetry/poetry#9820 For now, we've added a troubleshooting note on our end. However, we’d prefer not to modify the Makefile, as this change would need to be propagated (and later reverted) across 15+ projects, and the bug affects a relatively small number of contributors working on docs. Closing this PR for now, but please feel free to reopen or add comments if there’s anything further you’d like to discuss. |
|
@dgarcia360 Thank you, that makes sense. |
Python-poetry is affected by bug
python-poetry/poetry#8761. Namely, if you have "keyring" https://pypi.org/project/keyring/ installed, poetry will try to gain access to the Default collection in the (ex. GNOME) keyring, even if poetry only needs read-only access to package repositories, and even if those repos are public.
Consequently, you either unlock your Default collection for poetry (unjustifiedly), or your GUI session gets effectively locked up, because any time you hit Cancel on the keyring unlock dialog, poetry immediately pops up another, and this dialog grabs the keyboard -- you cannot even switch to a character VT, for killing poetry; you have to log in via ssh for that.
This issue is not visible to users who don't use "keyring" (GNOME or otherwise). For those who do, work around the problem by selecting the "null" keyring back-end, in the environment of every poetry invocation.
Note: I have not regression-tested the workaround in a desktop environment where "keyring" is unavailable to begin with.