Yep. I’d consider that more of an example, your case is still pretty simple - it’s an alternate way to implement the docs @waffle8946 linked earlier:
let
gi_typelib_path = lib.makeSearchPath "lib/girepository-1.0" [
pkgs.glib
# Any other packages with gobjects you want to introspect
];
in
pkgs.writers.writePython3 "myscript" {
libraries = with pkgs.python3Packages; [ numpy ];
# If you read the docs I link below, you can see that `makeWrapper`
# is exposed to all script writers like this.
#
# Unfortunately, `wrapGapps` *isn't* exposed, so we need to do
# this "manually". This may or may not become awkward depending
# on how involved your script actually is, at which point you should just
# make a custom derivation - which isn't much more complex tbh, this
# maybe saves 3 lines.
makeWrapperArgs = [
''--prefix GI_TYPELIB_PATH : "${gi_typelib_path}"''
];
} ./myscript.py
There is, unfortunately finding docs for many utility libraries requires actually looking inside the nixpkgs repo.
Google is universally unhelpful, especially these days, it’s become very enshittified. I really recommend having a clone of nixpkgs locally and getting good with ripgrep and/or a good editor with nice search functionality.
Should there be a good index into all nixpkgs functions with excellent SEO so that Google just magically works? Absolutely, unfortunately that doesn’t currently exist.
This is specifically a (pretty well-documented, once you find it) feature of the generic makeScriptWriter, which writePython3 is a specialization of.
You’re also welcome to add these docs upstream as you run into issues like this. It’s difficult for nixpkgs contributors to know what issues users will run into in practice, and what is not obvious to them. Most python packages are created semi-automatically anyway, so there’s nobody who would really have the level of ownership over pydbus specifically to realize this is needed; it’s just a very specific configuration. Most python libraries are just there because they are dependencies of other packages, and not really designed to be used for programming directly.
Plus, as your familiarity with glib, python, and nix grows, most of these types of errors become very obvious, making it easy to overlook the need for docs. And honestly, upstream has its hands full just keeping the lights on; cut them some slack.
The utility wrappers/scripts/etc. of nixpkgs absolutely do need more than just the in-code docs, and the docs that do exist probably do need some work too, it’s often not transparent what args do without reading the code. AIUI there’s some work in that direction (which is why the in-code docs are at least decent nowadays), but large parts are still underdocumented, and the reference docs remain very poorly structured.
Acknowledging that the current state isn’t perfect doesn’t really help you though, which is why pragmatically the only answer is to ask around here and/or gain experience yourself to the point that this stuff is trivial to you. And to read nixpkgs source code; once you become comfortable just doing that instead of assuming Google always has an answer the ecosystem really opens up a lot.