python3.pkgs.pygobject3: propagate gobject-introspection setup hook and glib #308488
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Will be fixed less invasively in next commit. This reverts commit dd897ed.
…nd glib
Previously, if a package just depended on GLib (or other bindings shipped with gobject-introspection), wrapper was not needed since `${gobject-introspection}/lib/girepository-1.0` is implicitly on typelib path. Now that GLib bindings were moved to `glib` package, `${glib}/lib/girepository-1.0` must be added to `GI_TYPELIB_PATH` by the wrapper (or `gobject-introspection` setup hook for build time).
This broke packages like `power-profile-daemon` at runtime and `python3.pkgs.pydbus` at build time.
While we cannot sensibly propagate wrapping, we can at least fix the build time issues by propagating `glib` and the g-i setup hook.
---
I believe it should be possible to use `pygobject3` without `GLib` bindings in theory, so propagating `glib` is not exactly correct. But since all practical projects will probably need `GLib` or `GObject` anyway, it might still be a a good idea to propagate `glib` from `pygobject3`.
We probably want to propagate `gobject-introspection.setupHook` from `pygobject3` all the time because without the environment variables set by the setup hook, no bindings will be available.
I do not think we do not want to propagate `gobject-introspection` since it now just contains typelibs for bunch of third-party libraries (e.g. cairo, fontconfig, xrandr…) which are not needed most of the time, the old libgirepository (which is usually only linked against) and build tools (needed for producing bindings, not for consuming them).
---
If `pygobject3` goes to `buildInputs` (`(0,1)`), `gobject-introspection.setupHook` should go to `depsBuildBuildPropagated` (`(-1,-1)`) in `pygobject3` to result in `(-1,0)` (`nativeBuildInputs`) in dependents, and `glib` should go to `depsHostHostPropagated` (`(0,0)`), if we want it in `(0,1)` (`buildInputs`). We cannot propagate `setupHook` attribute directly, since it is not a package, though.
ofborg
bot
added
11.by: package-maintainer
wegank
added
the
2.status: merge conflict
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes
Previously, if a package just depended on GLib (or other bindings shipped with gobject-introspection), wrapper was not needed since
${gobject-introspection}/lib/girepository-1.0is implicitly on typelib path. Now that GLib bindings were moved toglibpackage,${glib}/lib/girepository-1.0must be added toGI_TYPELIB_PATHby the wrapper (orgobject-introspectionsetup hook for build time).This broke packages like
power-profile-daemonat runtime andpython3.pkgs.pydbusat build time.While we cannot sensibly propagate wrapping, we can at least fix the build time issues by propagating
gliband the g-i setup hook.I believe it should be possible to use
pygobject3withoutGLibbindings in theory, so propagatingglibis not exactly correct. But since all practical projects will probably needGLiborGObjectanyway, it might still be a a good idea to propagateglibfrompygobject3.We probably want to propagate
gobject-introspection.setupHookfrompygobject3all the time because without the environment variables set by the setup hook, no bindings will be available.I do not think we do not want to propagate
gobject-introspectionsince it now just contains typelibs for bunch of third-party libraries (e.g. cairo, fontconfig, xrandr…) which are not needed most of the time, the old libgirepository (which is usually only linked against) and build tools (needed for producing bindings, not for consuming them).If
pygobject3goes tobuildInputs((0,1)),gobject-introspection.setupHookshould go todepsBuildBuildPropagated((-1,-1)) inpygobject3to result in(-1,0)(nativeBuildInputs) in dependents, andglibshould go todepsHostHostPropagated((0,0)), if we want it in(0,1)(buildInputs). We cannot propagatesetupHookattribute directly, since it is not a package, though.Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.