$ nix-locate girepository-1.0/GMenu
gnome-menus.out 5,964 r /nix/store/36sc4k17ypjxci29zp9yzcrzvpbj3jwv-gnome-menus-3.36.0/lib/girepository-1.0/GMenu-3.0.typelib
$ nix-locate girepository-1.0/GTop
libgtop.out 47,244 r /nix/store/gk73fj5p3980p2vif4q8pcq50k00wq9y-libgtop-2.40.0/lib/girepository-1.0/GTop-2.0.typelib
As mentioned, this does not make much sense, as libraries are not supposed to be installed. There are hacks to allow using globally installed GObject Introspection typelibs but they are very much against Nix philosophy.
“Applications Menu” should be installed by default.
I see that the example in the “GNOME section of Nixpkgs manual” is exactly about the problem I have. So if I understand correctly, there are 2 different situations.
For gnomeExtensions.applications-menu, the problem would be that I installed it, which probably retrieved an unpatched version (why?), while the patched version was already available as part of Gnome 3 (but I did not realize because extensions were not enabled).
But then, how do I know which extensions are already bundled with Gnome 3? In the Git repository linked to by the URL you gave, I see that gnome-shell-extensions is included in Gnome 3, but how do I see the metadata of an uninstalled package? → list of files, description, configuration options…
As for gnomeExtensions.system-monitor-2, I doubt it is included. So it was badly packaged?
Is there a way I can live-fix it while declaring its installation in configuration.nix?
We automatically package all extensions from https://extensions.gnome.org/ but the the official GNOME extensions packaged in gnome-shell-extensions package are bit of a special case since they are a part of a single project and are packaged together as such. We should either remove them from the list of automatically packaged extensions or make the attributes point to gnome.gnome-shell-extensions.
If you have both packages installed, there is probably a file conflict so Nix chooses the file it ¿sees first?
Since it is automatically packaged, it is indeed packaged incorrectly. The system is not smart enough and will require a human intervention. @piegames I wonder how hard it would be to scan extensions for typelib includes and resolve that automatically. Then again there are external dependencies on programs installed to PATH, which would be much harder to catch.
GNOME Shell extensions installed through Nix should work. If they do not please open a bug in Nixpkgs issue tracker.
I really do not mean to criticize or anything. I am just in the dark because Nix and NixOS are so new to me.
For example, I’ve read this blog post (hoping it is still relevant), and I am wondering if HomeManager would be a recommended tool to use, or if I should continue with users.users.*.packages in the main configuration… So much to discover!
Anyway, all you explained seems very sensible to me I’ll try and create issues in the Nixpkgs tracker when I see problems. It’s on GitHub, isn’t it?
Yes, that blog post still applies (though you need to replace gnome3 by gnome in package names and NixOS options).
I think the only reason Home manager is not officially recomended is because it is still a third party project. It is pretty nice for managing the GNOME configuration and what I personally use. But you can as well achieve that with plain NixOS configuration, which I did previously.
The dconf solution of home-manager is nicer in that you do not need to re-login after switching to the new configuration for the settings change to apply and it is not ignored if you change the settings in the app. But it is more error prone since you are not manipulating GSettings system but the backing database store.