-
Notifications
You must be signed in to change notification settings - Fork 1.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
dconf - Try to find a Python interpreter that has gi.repository.GLib #6491
Conversation
If we're invoked in a Python interpreter that doesn't have access to `gi.repository.GLib`, try to find one that does and respawn the task in that interpreter.
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.
Thanks for your contribution!
Co-authored-by: Felix Fontein <[email protected]>
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.
Mixed feelings about this "respawning" business - it feels like a McGyver solution to a problem that should not happen if the execution environment is built properly to begin with with.
That being said, I see that same mechanism used in apt_repo
, apt
, dnf
, dnf5
, package_facts
and yum
, as well as in c.g.portage
.
If we must, a slightly better way of doing this IMO would be to encapsulate that module-search-and-respawn logic into a function, drop it in module_utils.respawn
and use it in all those modules, instead of repeating that same code everywhere.
You're not wrong, but I would prefer not to have the work to refactor how this gets done piled onto me and hold up getting this change merged when I'm not a major contributor to the project and I'm just trying to make my module solve this problem the way that, as you pointed out, many other modules already solve it. |
That doesn't work since the Python libraries this module (and others you mentioned) need are part of the system libraries and only available for the system Python interpreter, and cannot be installed for any other Python interpreter without major hacks. Respawning is the least worst solution to this problem. |
Backport to stable-6: 💚 backport PR created✅ Backport PR branch: Backported as #6504 🤖 @patchback |
…6491) * dconf - Try to find a Python interpreter that has gi.repository.GLib If we're invoked in a Python interpreter that doesn't have access to `gi.repository.GLib`, try to find one that does and respawn the task in that interpreter. * ChangeLog fragment for #6491 * Update changelogs/fragments/6491-dconf-respawn.yml Co-authored-by: Felix Fontein <[email protected]> * Simplify import code * Get rid of ModuleNotFoundError --------- Co-authored-by: Felix Fontein <[email protected]> (cherry picked from commit 9f3c86a)
…nterpreter that has gi.repository.GLib (#6504) dconf - Try to find a Python interpreter that has gi.repository.GLib (#6491) * dconf - Try to find a Python interpreter that has gi.repository.GLib If we're invoked in a Python interpreter that doesn't have access to `gi.repository.GLib`, try to find one that does and respawn the task in that interpreter. * ChangeLog fragment for #6491 * Update changelogs/fragments/6491-dconf-respawn.yml Co-authored-by: Felix Fontein <[email protected]> * Simplify import code * Get rid of ModuleNotFoundError --------- Co-authored-by: Felix Fontein <[email protected]> (cherry picked from commit 9f3c86a) Co-authored-by: Jonathan Kamens <[email protected]>
SUMMARY
If we're invoked in a Python interpreter that doesn't have access to
gi.repository.GLib
, try to find one that does and respawn the task in that interpreter.ISSUE TYPE
COMPONENT NAME
dconf
ADDITIONAL INFORMATION
As suggested by @felixfontein in #6049 (comment) .