Skip to content

python3.pkgs.pygobject3: propagate gobject-introspection setup hook and glib#308488

Draft
jtojnar wants to merge 2 commits intoNixOS:stagingfrom
jtojnar:pygi-setup-hook
Draft

python3.pkgs.pygobject3: propagate gobject-introspection setup hook and glib#308488
jtojnar wants to merge 2 commits intoNixOS:stagingfrom
jtojnar:pygi-setup-hook

Conversation

@jtojnar
Copy link
Member

@jtojnar jtojnar commented May 2, 2024

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.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.

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

Will be fixed less invasively in next commit.

This reverts commit dd897ed.
@github-actions github-actions bot added the 6.topic: python Python is a high-level, general-purpose programming language. label May 2, 2024
…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.
@jtojnar jtojnar force-pushed the pygi-setup-hook branch from 386473b to 6e9e56e Compare May 2, 2024 10:22
@ofborg ofborg bot added 11.by: package-maintainer This PR was created by a maintainer of all the package it changes. 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 1001-2500 This PR causes many rebuilds on Darwin and should most likely target the staging branches. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches. labels May 2, 2024
@wegank wegank added the 2.status: merge conflict This PR has merge conflicts with the target branch label May 22, 2024
@vcunat vcunat changed the base branch from staging-next to staging June 29, 2024 08:07
@wegank wegank added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jan 2, 2025
tpwrules added a commit to tpwrules/snakeeyes-wireless that referenced this pull request Mar 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

2.status: merge conflict This PR has merge conflicts with the target branch 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md 6.topic: python Python is a high-level, general-purpose programming language. 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 1001-2500 This PR causes many rebuilds on Darwin and should most likely target the staging branches. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches. 11.by: package-maintainer This PR was created by a maintainer of all the package it changes.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants