Nixpkgs: setup hook of gobject-introspection in nativeBuildInputs does not run with strictDeps

[emmanuelrosa]

Issue description

virt-manager fails to load and instead produces the error "Namespace LibvirtGLib not available"

Traceback (most recent call last):
  File "/nix/store/b8na689bifds8z2xg1bragbw54mznppa-virt-manager-2.1.0/share/virt-manager/virt-manager", line 17, in <module>                                                                   
    gi.require_version('LibvirtGLib', '1.0')
  File "/nix/store/kiw47xswi1041sbvbgrlfy0xs0zlwyvk-python3.7-pygobject-3.30.4/lib/python3.7/site-packages/gi/__init__.py", line 129, in require_version                                        
    raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace LibvirtGLib not available

I'm aware of #33754 and #34000. I have the changes in the merged commit. Yet, I receive the error.

Steps to reproduce

1. Install virt-manager
2. Open a terminal and run virt-manager

Technical details

• system: "x86_64-linux"
  
  
  
  • host os: Linux 4.14.104, NixOS, 19.09.git.27cb066 (Loris)
  
  
  • multi-user?: yes
  
  
  • sandbox: yes
  
  
  • version: nix-env (Nix) 2.2
  
  
  • channels(root): "nixos-19.09pre171582.26d8a8c0eb2"
  
  
  • nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos
  
  

NOTE: My nixpkgs is not as shown above but rather a clone of this repo at commit 27cb0669c61703fdcb2a496d8ff1157c394e0f8d

[jtojnar]

I think this is another issue caused strictDeps being enabled for Python packages (https://github.com/NixOS/nixpkgs/pull/54182); I also noticed it in https://github.com/NixOS/nixpkgs/pull/56783#discussion_r261937090.

strictDeps probably prevents the setup hook in nativeBuildInputs from running; though, I would expect hostOffset to work:

https://github.com/NixOS/nixpkgs/blob/51174e7b7b464519f65cd878c0c668b4325fb2d1/pkgs/development/libraries/gobject-introspection/setup-hook.sh#L13

We will need to fix the setup hook? cc @Ericson2314 @hedning

[Ericson2314]

gobject-introspection is a terrible thing that makes cross compilation impossible. Try adding it as both as a buildInput and nativeBuildInput to get native builds working.

CC @Eternaleye

[jtojnar]

Is there nothing else we can do to make addEnvHooks "$hostOffset" work with the setup hook?

[jtojnar]

It is even more serious

with import <nixpkgs> {};
stdenv.mkDerivation {
  name = "setup-hook-test";
  unpackPhase = ":";
  dontBuild = true;
  nativeBuildInputs = [ wrapGAppsHook ];
  installPhase = ''
    runHook preInstall
    mkdir -p $out/bin
    touch $out/bin/test
    chmod +x $out/bin/test
    runHook postInstall
  '';
}

does not even pick up the librsvg dependency

https://github.com/NixOS/nixpkgs/blob/4a48f6ac98bf3b389cc854840bb059b0a9e8241a/pkgs/top-level/all-packages.nix#L394-L396

for GDK_PIXBUF_MODULE_FILE. Curiously, it detects dconf; and multiple times at that:

#! /nix/store/cinw572b38aln37glr0zb8lxwrgaffl4-bash-4.4-p23/bin/bash -e
export GIO_EXTRA_MODULES='/nix/store/h9wqk3nx4h020xrvha2si7y01alk337w-dconf-0.30.1-lib/lib/gio/modules'${GIO_EXTRA_MODULES:+':'}$GIO_EXTRA_MODULES
export GIO_EXTRA_MODULES='/nix/store/h9wqk3nx4h020xrvha2si7y01alk337w-dconf-0.30.1-lib/lib/gio/modules'${GIO_EXTRA_MODULES:+':'}$GIO_EXTRA_MODULES
exec -a "$0" "/nix/store/16khixg577v3f2bdfs30mhj6n8l6hsq2-setup-hook-test/bin/.test-wrapped"  "${extraFlagsArray[@]}" "$@"

are setup hooks not propagated any more? If I add gdk-pixbuf, librsvg will suddenly be picked up:

with import <nixpkgs> {};
stdenv.mkDerivation {
  name = "setup-hook-test";
  unpackPhase = ":";
  dontBuild = true;
  buildInputs = [ ];
  nativeBuildInputs = [ wrapGAppsHook gdk_pixbuf ];
  installPhase = ''
    runHook preInstall
    mkdir -p $out/bin
    touch $out/bin/test
    chmod +x $out/bin/test
    runHook postInstall
  '';
}

#! /nix/store/cinw572b38aln37glr0zb8lxwrgaffl4-bash-4.4-p23/bin/bash -e
export GIO_EXTRA_MODULES='/nix/store/h9wqk3nx4h020xrvha2si7y01alk337w-dconf-0.30.1-lib/lib/gio/modules'${GIO_EXTRA_MODULES:+':'}$GIO_EXTRA_MODULES
export GIO_EXTRA_MODULES='/nix/store/h9wqk3nx4h020xrvha2si7y01alk337w-dconf-0.30.1-lib/lib/gio/modules'${GIO_EXTRA_MODULES:+':'}$GIO_EXTRA_MODULES
export GDK_PIXBUF_MODULE_FILE='/nix/store/w073vf5lhf08n1pg77qsinq5qqdaymqy-librsvg-2.44.12/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache'
export XDG_DATA_DIRS='/nix/store/ialw7015yr8wm578d4j09fi3ay5hk96c-gtk+3-3.24.5/share/gsettings-schemas/gtk+3-3.24.5:/nix/store/ialw7015yr8wm578d4j09fi3ay5hk96c-gtk+3-3.24.5/share/gsettings-schemas/gtk+3-3.24.5:/nix/store/ialw7015yr8wm578d4j09fi3ay5hk96c-gtk+3-3.24.5/share/gsettings-schemas/gtk+3-3.24.5'${XDG_DATA_DIRS:+':'}$XDG_DATA_DIRS
exec -a "$0" "/nix/store/pfk5qj7gnhjzkmklyns7svdmqqc8afkh-setup-hook-test/bin/.test-wrapped"  "${extraFlagsArray[@]}" "$@"

But I guess since librsvg is propagated by the hook in nativeBuildInputs it will be the native version. We would need to propagate it to offset -1. All this bash magic makes my head tumble.

[FRidh]

As a last resort strictDeps could be disabled for this expression.

[jtojnar]

Still need to fix the underlying issue.

[Ericson2314]

Listing twice is not a hack in my mind. It is the proper way to indicate that a dependency is both a build and run time dependency.

[Ericson2314]

For that second issue, I don't remember setup hooks being automatically propagated ever, but a setup can propagate a dependency that it will itself pick up.

[jtojnar]

Well, in my mind, it is not a run time dependency (at least not a direct one). Most of the time, it is only used during build for the setup hook.

[jtojnar]

After discussion on IRC we have decided to move make_gobject_introspection_find_gir_files and giDiscoverSelf into a separated setup hook and to add make_gobject_introspection_find_gir_files to $targetOffset.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/modulenotfounderror-no-module-named-gi/6874/3

[stale[bot]]

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.