What is your approach to packaging Wine applications with Nix derivations?

Help
1

I am curious about existing approaches to packaging applications that run via Wine within Nix derivations. I have come across the desire to do so a few times over the past couple of years, but never had the time to work out how to achieve this nicely.

While there are quite a few posts discussing specific Wine packages, I thought it might be worth opening a dedicated post where Nix users can share solutions they’ve used, discuss the challenges, and possibly come up with some ideas for a general solution or expression that we could eventually land in nixpkgs itself.

As far as I’m aware there isn’t yet a “standard” or go-to solution for packaging Wine applications - please correct me if I’m wrong!

From what I’ve read there are some challenges in handling the amount of mutability required by some applications, though I’m sure there is probably a function or two that could at least ease the general process.

All that said, I think even just consolidating some examples in one place would be really useful.

Here are some related links I’ve discovered so far:

While I imagine it might not be common to include Wine applications in nixpkgs itself (particularly as they often require having an existing executable, are unfree, or break between different versions of Wine which might be a bit much to ask of maintainers), I can imagine a general wrapWine function or something along those lines would still be a great help for declarative packaging downstream, whether for personal tools, video game archival, that one Windows-only program your job requires, etc.

10 Likes
2

Hi o/

I am the author of wrapWine (aka lucasew).

Most windows apps (to not say all) doesn’t work running from a read only place (nix-store) so my idea was to generate everything on first run.

wrapWine generate a script that on the first run initialize a wine prefix with the passed wine version, install all the tricks in the list with winetricks and can run custom setup and run scripts.

For the generated script if you setup the REPL environment variable it starts a bash shell inside the prefix context. This is useful AF for troubleshooting.

And yea. I got a few games working nicely using this approach. If the prefix is f up you just delete it (it’s a folder inside ~/.wine-nix and it will generate on next run.

I already (like I said) run a few repacked games, TORA and 7-zip.

It’s working pretty nice and I think it’s the simplest approach for this problem, more elegant and simple than use something like PlayOnLinux and I can run my software from any folder.

Some games crash if you don’t launch them chdired on their folders.

I am looking to upstream this to nixpkgs but I am a bit low in time. Also I made a wrapper script to launch borderless chrome-like windows. It’s useful to have more screen use but without hiding the polybar.

7 Likes
3

I’m unsure how well this will play out with Anticheat support that is coming to linux.

1 Like
4

The approach I’m using is based on wrapWine. It’s a script which creates a Wine bottle and installs a Wine-compatible application, but it uses a Docker-like layered filesystem approach to create something like a Nix store, but in the user’s home directory.

It makes Windows application management more Nix-like, with support for installing multiple versions and rolling back. Just like any other Nix package. You can read more about it here: https://github.com/emmanuelrosa/erosanix/tree/master/pkgs/mkwindowsapp

Some example packages include:

7 Likes
5

Great approaches!

Even though it’s not packaging, I’d like to present my approach. As a developer I often use nix-shells to handle complex development environments, where I need the tools but don’t install the “main thing”. Even though the reason here would be a bit different, the approach is very handy with wine too. For each game I have a folder with shell.nix, Makefile and the setup file (or similar). shell.nix creates environment with the correct wine version and Makefile handles installing and running the game (including entering the nix-shell). WINEPREFIX is set to a folder within that folder. To avoid rebuilding wine after GC, I use the secret attribute inputDerivation to set the wine build as a garbage root.

3 Likes