Struggling with NixOS: Can't figure out how to get some apps to work without crude hacks

[jjramsey]

@TLATER

Imagine the pain if you didn’t do that work and it suddenly stopped working just because you installed a random package with a schema that happens to share a name with yours. Oh, wait, that’s how it works on traditional distros.

Actually, that looks more like a situation that could happen if I was careless in installing stuff from the AUR. Heh.

@TLATER

You’re seeing some resistance here, because it’s kind of like running into the Rust forums and complaining about the lack of an Any type. [I’m guessing that you mean that Rust lacks the kind of dynamic typing that Python has, where a variable can readily be assigned to an integer, then a string, then to any other type. Rust does seem to have type similar to the boost::any or std::any seen in C++: https://doc.rust-lang.org/std/any/index.html.]

I think that’s half true. The other half is that when things break on NixOS due to a lack of global runtime information, it isn’t obvious that the problem is missing runtime information. At first, it just looks like random breakage.

In some cases, that’s because a package is packaged incorrectly. That seems to be the case for the Workrave package, which does come with a GNOME extension – but one that isn’t patched for use with NixOS. Looks like a partial solution to that is at “Gnome extention Hanabi on nixos - #12 by jtojnar”, and if that works with my hacked version of the Workrave extension, that would obviate a need to mess with XDG_DATA_DIRS, and I can add that information to my bug report for the Workrave package.

In other cases, the underlying problem is that some piece of software can’t be patched or wrapped to transparently work with NixOS – as seems to be the case with some Python modules – and the user needs to step in with some manual workarounds.

Documentation would likely help with that other case. If pydbus and dasbus had in their longDescription strings some warning that they require certain runtime information, the symptoms of what it looks like when it’s missing, such as error messages, and steps to take to fix the problem (e.g., set an environment variable in configuration.nix for a quick-and-dirty solution, use some kind of wrapper like wrapGAppsHook* if packaging an app that uses pydbus, maybe do something with nix-shell (?) if using those Python modules, etc.) Things would have been so much easier for me if Googling the error message would point me to the description of packages with that kind of long description!

It wouldn’t even be that hard for the packager to test for likely use cases. For a Python module in particular, seeing what happens at a REPL when a user uses the module according to its documentation would be an obvious go-to. For a GNOME extension, well, try it and see if it works.

If the NixOS developers are going to insist on avoiding global state, they can at least also insist on documenting workarounds so that users don’t have to waste time with guesswork.