Pygobject3 fails gi.require_version('Notify', '0.7')

I’m trying to use Gnome3’s Notify interface from python. In nixpkgs, I can’t see how one can generate the needed gobject-introspection Notify-0.7.gir file or get pygobject3 to use it.

It is part of libnotify package. gobject-introspection’s setup hook will populate the variable, see also How to have gst and gtk in python? - #3 by jtojnar

1 Like

I’m a bit new at all this. For example I currently have an overlay with:

myPythonEnv = self.python3.withPackages
(pkgs: with pkgs; [

Could I somehow have a my_pyobject3 as a override on pygobject3 and add a libnotify dependency
and then somehow get gobject-introspection’s setup hook activated.

This goes beyond python environment. You could have something like

myEnv = super.mkShell {
  name = "my-env";
  nativeBuildInputs = [ super.gobject-introspection ];
  buildInputs = [ self.myPythonEnv super.libnotify ];

Thanks. That gives me something that works. Now I can try to understand what is going on, and how to use it outside of a nix-shell.

Should be the same outside of mkShell. Also read our GNOME platform docs.

This works for application that are installed in the environment, not in the python3.withPackages type general setup.

Its interesting the Python3Full uses special cpython’s mkDerivation hooks to get the environment setup for x11support. Maybe I was expecting a similar Gnome hooks when pygobject was used.

I’ve now figured out several ways to do what I wanted, although I’m left with a confusion about whether attempting to allow simple python #! scripts using pygobject in my own environment was something that could cause problems.

Not sure what does this mean.

That is for linking the ELF files, I presume. GObject is more dynamic and thus cannot be really linked in a cleaner way then by setting environment variables in a wrapper script. (I will refer you to the GNOME platform docs again.)

Sorry, it been taking a bit of time to digest what is going on, between how Nixos, Gnome, and Python all fit together. I have a variety of ‘#! /usr/bin/env python’ scripts developed on more conventional OS setups, and was wondering if I had to create buildPythonApplication ‘.nix’ files for some of them to ‘nix-env --install’. The answer seem to be yes.

However, I could get things to work by installing my myPythonEnv and setting GI_TYPELIB_PATH in my .profile to find any missing .typelib files from my
~/nix-profile/lib/girepository-1.0 or /run/current-system/sw/lib/girepository-1.0 tacked on to the end of the
path already set from (what I assume is) the gnome-shell wrapper and reading /etc/profile.

The more I think about it, the more I feel the latter approach is distasteful.

Yeah, installing stuff like that globally is a bad practice:

Instead nix-shell is the recommended tool to provide dependencies to scripts. You can even use that in shebang:

Example: 'gi.repository.Gst' object has no attribute '_overrides_module' · Issue #41711 · NixOS/nixpkgs · GitHub

Moving from other systems does require changing some preconceptions. I had been avoiding nix-shell based scripts, but am starting to see some benefits.

They seem to fit a grey area between simple scripts that have no real setup needs and full applications that require an install even on non-nix based systems. They do, however, have no protection from nix garbage collection and a performance cost.

There are also tools like lorri and cached-nix-shell. The latter explicitly supports shebangs.