update umu-launcher: add attrs extraLibraries & extraPkgs

[LovingMelody]

Add extraLibraries & extraPkgs to package attrs to allow passing graphical libs. This is needed for dxvk-nvapi to work on NVIDIA cards.

Example from Steam of this being used:

nixpkgs/nixos/modules/programs/steam.nix

Lines 51 to 57 in 9588b84

	extraLibraries = pkgs: let
	prevLibs = if prev ? extraLibraries then prev.extraLibraries pkgs else [ ];
	additionalLibs = with config.hardware.graphics;
	if pkgs.stdenv.hostPlatform.is64bit
	then [ package ] ++ extraPackages
	else [ package32 ] ++ extraPackages32;
	in prevLibs ++ additionalLibs;

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• [] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[MattSturgeon]

No issues from me

[diniamo]

@diniamo please don't 👎 without leaving a review explaining your position

I did, twice, on the original PR. Both times it was ignored, so I see no point, but let's do it anyway then.

This makes sense for game launchers, because games may require arbitrary libraries to work. But that isn't the case for Windows games, since every dependency is either bundled in wine, or can only be installed in the wine prefix imperatively. Now considering that, and the fact that umu-launcher can only launch Windows games, we get that we wouldn't normally need extra packages in the FHS env. If for some reason we do anyway, then that can be added as a withSomething option (this makes sense for the nvidia dxvk thing), or using overrideAttrs (this makes sense for the cursor fix, since it's a temporary workaround (?)).

[MattSturgeon]

I did, twice, on the original PR. Both times it was ignored

Sometimes it's easier to have these discussions on dedicated issues/PRs (like this one). My interpretation of this thread wasn't that it was ignored, but rather that discussion was postponed until after that PR was done.

Now considering that, and the fact that umu-launcher can only launch Windows games, we get that we wouldn't normally need extra packages in the FHS env.

Makes sense, sure.

If for some reason we do anyway,

However, from a pragmatic perspective, if we occasionally need extra packages anyway, why not make it easier for users to specify them?

I don't see any downsides to having the code, even if it is only occasionally useful.

then that can be added as a withSomething option (this makes sense for the nvidia dxvk thing)

Sure, if there's well known common work-arounds they could be added as withSomething or enableSomething options. I don't see that as being mutually exclusive.

[diniamo]

if we occasionally need extra packages anyway

This is the exact reason overrideAttrs exists.

[LovingMelody]

@diniamo please don't 👎 without leaving a review explaining your position

I did, twice, on the original PR. Both times it was ignored, so I see no point, but let's do it anyway then.

This makes sense for game launchers, because games may require arbitrary libraries to work. But that isn't the case for Windows games, since every dependency is either bundled in wine, or can only be installed in the wine prefix imperatively. Now considering that, and the fact that umu-launcher can only launch Windows games, we get that we wouldn't normally need extra packages in the FHS env. If for some reason we do anyway, then that can be added as a withSomething option (this makes sense for the nvidia dxvk thing), or using overrideAttrs (this makes sense for the cursor fix, since it's a temporary workaround (?)).

Nvidia can't be added as a withSomething flag because it has to be the library from your driver version. The only way to get this is to get it from config, I wish this wasn't the case, but it is.
There is an open issue for it #177533, but this is what the standard practice is now. Steam, heroic, lutris also do it this way. As mentioned in the original pr, Steam uses this to pass graphical libraries for the user when programs.steam.enable is used. This isn’t specifically for Linux native games.

[MattSturgeon]

if we occasionally need extra packages anyway

This is the exact reason overrideAttrs exists.

For the record, overrideAttrs isn't helpful in this case.

targetPkgs isn't a derivation attr, it's an argument to buildFHSEnv. Therefore it can't easily be overridden.

[LovingMelody]

For the record, needs to be in the fhs environment for dxvk-nvapi to locate it.

[MattSturgeon]

Thanks for working on this!

[MattSturgeon]

Wow nixfmt has made that ugly 💥 🚒

IDK if this is still the case, but it used to format things nicer if you made the list-literal the last part of the expression:

Suggested change

	targetPkgs =
	pkgs:
	[
	# Use umu-launcher-unwrapped from the package args, to support overriding
	umu-launcher-unwrapped
	]
	++ extraPkgs pkgs;
	targetPkgs = pkgs: extraPkgs pkgs ++ [
	# Use umu-launcher-unwrapped from the package args, to support overriding
	umu-launcher-unwrapped
	];

No big deal, either way 🙂