New tag for non-standalone packages in search.nixos.org

1

Hi, this is a feature suggestion that would apply to the package metadata in nixpkgs as well as a frontend tweak in search.nixos.org.

I recently tried to run gpu-screen-recorder-gtk on my system via nix run so that I could record my screen. Turns out, this package doesn’t work if you install it via systemPackages or nix run/nix shell like I did, but rather requires to be configured via options via programs.gpu-screen-recorder.enable to do the necessary system-wide tweaks.

I’ve heard that it’s always better to use options to configure apps, but this made me wonder:
If I can’t guarantee that an app installed without options (“without options” being referred to “standalone” in this post) is going to work properly, should I always have to look up options first and then the app?

My friend found this in the manual (the first note):

Some packages require additional global configuration such as D-Bus or systemd service registration so adding them to environment.systemPackages might not be sufficient. You are advised to check the list of options whether a NixOS module for the package does not exist.

Since the existance of a package is necessary for the NixOS module to work, so the option, shouldn’t packages be marked if they only work when configured via the options or if it can also be installed standalone?

I’d like to propose that all packages are marked with a new metadata field (e.g. standalone_status) that has the following options for this:

  • unknown: the default value unless the developer changes it
  • broken: it doesn’t work when installed on its own, like gpu-screen-recorder-gtk
  • experimental: the maintainer hasn’t tested this extensively, and/or maintains the package while focusing on a config with the options
  • functional: the package fully works when installed standalone

It sounds like a good idea to display this information in search.nixos.org in some way so that the users know which package will “just work”.

I think it also makes sense to throw a warning when evaulating packages with the status broken, and possibly experimental in the terminal, i.e.:

$ nix shell nixpkgs#gpu-screen-recorder-gtk
Warning: gpu-screen-recorder-gtk has standalone status "broken", and thus should be configured in the options to work properly
$

This makes sense to me as a Nix/NixOS user who relies on search.nixos.org. Note that I’m not a NixOS maintainer.

I look forward to the discussion.

Best regards,
Luka

3 Likes
2

I agree with the general idea. I just want to point out that maybe instead adding links from the package to the option would be better.

Also nixpkgs can be used to build other distros than nixos. Finix, not-os, liminix, nixng, nix-darwin, so that has to be taken into account when throwing the warnings.

7 Likes
3

I don’t think this exact solution will work since most modules have some form of adding packages to environment.systemPackages, yet that will work in the context of the broader module that includes config. We don’t really have a way to differentiate a user doing that in their own config vs nixpkgs doing it.

2 Likes
4

Shame there’s no way to differentiate that.

But you could omit the warning, it was just an idea. People would still find the package on search.nixos.org or using nix search (I don’t use that), and see the warning there. Since this warning only makes sense for people installing apps that way.

5

Maybe just a meta.nixosModuleAvailable attribute, without making (expensive to maintain) claims about how thoroughly tested the package is with or without the module, would suffice here (if threaded through to the frontend with a ‘There is a NixOS module available for this package’ message)?

7 Likes
6

Though it’s recommended to generally use NixOS modules instead of the packages directly, this still sadly doesn’t provide information if it’s going to work in a “standalone” way.

I think the status of the package would be beneficial, especially since setting an option and rebuilding is arguably more effort than running a quick nix shell if the user is just testing out a package.

7

I like the general idea as well. What I’m not sure of is how to test that as a maintainer.

Especially graphical applications will be tested on whatever setup the maintainer has and those can contain silent dependencies.

Can an application that kinda only really works “out of the box” on Gnome for instance be called standalone or not? There is not any particular module you need to enable. Yes, services.desktopManager.gnome.enable = true; (or the plasma equivalent) will make it work if you’re using Gnome/Plasma, but it might very well run just fine, out of the box, if your Niri setup includes the needed setup to make it work.

Neither are truly “standalone”, but for most setups adding the package to your system config is enough to make it work.

This is more me thinking aloud than actual criticism.

2 Likes
8

There’s an issue on a similar topic: Missing Documentation/Feature: Preferred install option for packages · Issue #540501 · NixOS/nixpkgs · GitHub

2 Likes
9

I agree with @nadir’s point, sadly. We can’t assume a user does or doesn’t have gnome installed, or that they are or aren’t using NixOS.

A compromise might be a field called meta.installationHints, which could be shown prominently iff it’s non-empty.

1 Like
10

I wonder if .meta.description could be “misused” for a human hint that a module/wrapper/whatever is preferred.

3 Likes
11

@vcunat: I mean at the very least that’s a great temporary workaround.

1 Like
12

We already have that information, there’s no need to add it redundantly: Back in 2024 @erictapen already correctly proposed to index modules with a package option and map the default value back to the package search. (Related discussion: Zürich 24.11 ZHF hackathon report) This is a fix that can be done entirely at the search end of things, and would fix the worst part of “searching a package while you need the module” problem.

11 Likes
13

That’s a good way to do it! Not only the default value, but any packages in the relatedPackages attribute on the package option too.

6 Likes
14

If I understand you correctly, this doesn’t solve the problem that running nix run nixpkgs#some-pkg can be completely unsupported for some packages. Ideally, nix run, nix profile add, nix shell, nix-shell, etc. woud all inform the user that a specific package is only available for NixOS/nix-darwin/home-manager and not *-linux / aarch64-darwin in general.

1 Like
15

Yes, but that’s not a problem Nix should try to solve. It’s a matter of how to organise Nixpkgs and NixOS, respectively. Nix already knows way too much about the layers above it, and that makes life miserable for anyone trying to address that sort of UX issues. Currently a primary component of Nixpkgs UX is owned by Nix, no one is working on fundamentally changing that (AFAIK), and that’s one big reason why we can’t have nice things.

5 Likes