init: workarounds.nixgl module #5332
Conversation
michaelCTS
changed the title
michaelCTS
changed the title
michaelCTS
force-pushed
the
feat/add-nixgl-workaround
branch
2 times, most recently
from
4f9475c to
2fc2d54
Compare
michaelCTS
changed the title
michaelCTS
force-pushed
the
feat/add-nixgl-workaround
branch
2 times, most recently
from
1e9c8b7 to
b746b29
Compare
michaelCTS
changed the title
|
Well, I tried adding tests, but for some reason this fails { lib, pkgs, ... }:
with lib;
{
config = {
workarounds.nixgl.packages = with pkgs; [{ pkg = alacritty; }];
nmt.script = ''
assertFileRegex .nix-profile/bin/alacritty 'exec "/nix/store/.*/bin/nixGL" .*/alacritty'
assertLinkExists .nix-profile/share/applications/Alacritty.desktop
'';
};
}It doesn't find the files even though when I run |
michaelCTS
changed the title
| "Name of the nixGL binary to be called from within the wrapper package"; | ||
| }; | ||
| wrapperPkgPath = lib.mkOption { | ||
| type = lib.types.listOf lib.types.str; |
There was a problem hiding this comment.
If the paths are stable in nixGL then perhaps this could be enum [ "nixGLDefault" "nixGLNvidia" "nixGLNvidiaBumblebee" "nixGLIntel" ]? The module can know the corresponding attribute path.
There was a problem hiding this comment.
If so then can rename the option to something like wrapperFlavor or something.
There was a problem hiding this comment.
I'm not sure, honestly. There seems to also be nixGLNvidiaBumblebee and nixVulkanNividia according to the README. If we introduced an enum that would make users unable to target them.
| You can download the nixGL version of your choice and point to it here. | ||
| ''; | ||
| }; | ||
| wrapperBinName = lib.mkOption { |
There was a problem hiding this comment.
Is the binary ever called something other than nixGL?
There was a problem hiding this comment.
Yeah, seems like nixGLNvidia, nixGLNvidiaBumblebee, and others exist.
| It's expected to have a `pname` attribute. | ||
| ''; | ||
| }; | ||
| }; |
There was a problem hiding this comment.
Can just set the binary option directly in the submodule:
| }; | |
| }; | |
| config = { | |
| binary = mkOptionDefault (config.package.meta.mainProgram or getName config.package); | |
| }; |
Can then remove allowing null values.
There was a problem hiding this comment.
I'm not able to get this to work. It says attribute "package" missing. I tried binary = mkOptionDefault (config: (config.package.meta.mainProgram or getName config.package)); hoping the function would be evaluated, but it doesn't.
|
Thanks for the contribution! I've added a bunch of, hopefully, useful comments. Note, to actually include the module you need to add it to the |
|
I'm really happy that you found the time and will to make a pull request! Many of us have built our own hacks and workarounds, and will appreciate having a solution as part of HM. I haven't had the time to try this yet, but just looking at the interface, I'm a bit surprised that you chose to implement a list of packages to enable nixgl for. Having followed the various discussions, I got the impression that most of us went with wrapper functions. Is there a particular reason why you chose to go with a list of packages instead? One reason why a wrapper is more convenient is that you can wrap a package regardless of where it's used, be it in One more question: does this module require building the home configuration with |
The option allows packages to be wrapped by nixgl in order to make GUI applications work when installed with home-manager It also adds a wrapper to individually wrap packages
michaelCTS
force-pushed
the
feat/add-nixgl-workaround
branch
from
b746b29 to
de92ec7
Compare
|
@rycee I addressed your comments and applied the changes. Additionally, I added the wrapper to programs.kitty = {
enable = true;
package = config.lib.nixGl.wrap { package = pkgs.kitty; };
};
@exzombie I have no idea what that does. It works without that for me. |
|
Closed in favor of #5355 |
Description
The option allows packages to be wrapped by nixgl in order to make GUI applications work when installed with home-manager. The goal of this PR is just to make it easy to use graphically accelerated programs installed with home-manager in a desktop environment.
No need to install and run
nixGL $program. Just add the package toworkaround.nixgl.packageslike so[ { pkg = pkgs.some_package; }].Anything more advanced can come in further PRs by other people.
Checklist
Change is backwards compatible.
Code formatted with
./format.Code tested through
nix-shell --pure tests -A run.allornix develop --ignore-environment .#allusing Flakes.Test cases updated/added. See example.
Commit messages are formatted like
See CONTRIBUTING for more information and recent commit messages for examples.
If this PR adds a new module
Maintainer CC
Closes #3968