After using wrapper-manager and found some issues that would require major changes to the project (e.g., primarily uses wrapProgram instead of makeWrapper which led to some issues with the module design among other things), I’ve developed my reimagining of wrapper-manager that fixes those issues.
I assume most who would read this are already familiar with wrapper-manager so here’s a non-exhaustive list of differences with the original version. Also, there’s more listed differences in a dedicated section at the user guide.
It has integration modules for home-manager and NixOS.
More integrations have been added such as adding XDG desktop entries and base directories, and adding arbitrary files ala-environment.etc from NixOS.
Support for shell- and binary-based wrappers.
There’s more to expect from this project (which I didn’t expect when first developing this project). Among other things, when time allows, there would be modules for creating dedicated wrappers with Boxxy and Bubblewrap (both of which have working versions, just need more testing).
Anyways, let me know what you think and feel free to leave feedback in using this project (preferably over at GitHub).
That looks pretty cool! But no I wasn’t familiar with wrapper-manager, and a one-paragraph description what this is roughly about would have helped me appreciate it faster. The documentation is quite verbose and it was hard for me to filter what I wanted to know about it.
Do I understand correctly that this is a module-system based (i.e., typed) library for conveniently creating wrappers around executables from derivations?
It seems to come with lots of batteries included, really neat!
One reason I find this intriguing is that at some point I realised that NixOS is a uniform, strongly-typed interface to running services on and configuring your operating system; something that before NixOS was a real hassle. The next evolutionary step is having a uniform, strongly-typed interface to running just any program. This is roughly the direction wrapper-manager takes. What’s missing is a typed layer for passing environment variables and arguments to executables, which would faithfully model the application-specific parameters.
Ah whoops, I didn’t took the time to completely describe it as a standalone project. I suppose the documentation (esp the intro) is too reliant on the assumption that the user is already familiar with the original version.
Yesiree. I would describe it as a declarative interface over makeWrapper plus some other integrations.
Yay! Nice to see someone with a similar viewpoint for considering what’s next for the module system.
In fact, the reference to makeWrapper didn’t help me much either, because that’s yet another implementation detail that is very specific to Nixpkgs.
Side note: I don’t even fully understand why makeWrapper is still a thing at all (except historic reasons and inertia), because it seems to be a bash wrapper parameterised at build time — that’s very counterintuitive for me, because we already have the Nix language for parameterising things. There’s probably some trade-offs I’m not aware of.