-
-
Notifications
You must be signed in to change notification settings - Fork 127
Add a way to wrap nix derivations with makeWrapper #133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
| paths = [ drv ]; | ||
| buildInputs = [ pkgs.makeWrapper ]; | ||
| postBuild = '' | ||
| # This will break if wrapProgram is ever changed, so fingers crossed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are not using wrapProgram directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I know, there's no way to tell makeShellWrapper to make an actual wrapper in the sense that nixGL wraps stuff, so I overrode it with what we need here.
I still wanted to use wrapProgram though because it has some logic to correctly deal with multiple layers of wrapping.
If you think it would be better I'll inline it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Double wrapping as you describe it should be avoided as much as possible as it is very hard to get right. I think it would probably be an idea to modify the existing wrappers to fit your usecase to create one wrapped binary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be misinterpreting that, but my reading of the code is that this is what wrapProgram is for. I'm actually wrapping mixxx twice myself (nixGL and adding LD_LIBRARY_PATH for jack), and I'm pretty sure the package adds another wrapper itself.
This is obviously not optimal, but it makes things somewhat composable.
Anyways, I don't think we really have something to argue about here. I just found this solution for myself and thought it would be valuable to share.
I'm personally a bit hesitant to propose using wrapProgram directly because it will not work on packages which use a wrapper internally.
It's your decision what to put in the readme, I'm just offering a suggestion from my personal point of view.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I know, there's no way to tell
makeShellWrapperto make an actual wrapper in the sense thatnixGLwraps stuff, so I overrode it with what we need here. I still wanted to usewrapProgramthough because it has some logic to correctly deal with multiple layers of wrapping. If you think it would be better I'll inline it.
You should be able to do it the same way that electron programs are handled in nixpkgs
makeWrapper ${electron}/bin/electron $out/bin/${pname} \
--inherit-argv0 \
--add-flags $out/share/${pname}/resources/appAlso please use makeBinaryWrapper, inherit-argv0 works better with it AFAIK.
Co-authored-by: Sandro <[email protected]>
|
Home Manager now has this sort of wrapper script. I could still see it being useful to have here for users who aren't using home manager, though, like dev shells or builds on non-NixOS. How similar is this approach to that one? Could we just adopt it here and then have HM call the wrapper from this package? Presumably HM would still handle making it into a no-op in cases where nixGL is not set. |
I can't be bothered to remember adding
nixGLand I'm sure I'm not the only one.