Nixpkgs: WINE configuration?

[joepie91]

Not sure whether to file this on Nix or nixpkgs... Since _somebody_ around here is maintaining a WINE package, I figure I might as well ask it here :)

Anyhow, my usecase is wanting to build a Nix package for a Windows application, against a specific version and configuration of WINE, as well as a specific set of runtimes (think PlayOnLinux-style or winetricks, but preferably without either of those). How would one typically approach this with Nix?

I have no issues with reimplementing functionality for this if needed, I'm just not really sure what the packages would look like; the "bigger picture", so to say. My knowledge of Nix is still limited (especially where it concerns "plugin"-like things, like Windows runtimes under WINE), so I could use some direction here.

I should note that I don't necessarily need this to be merged into nixpkgs; hence my uncertainty where to file this issue.

[Ericson2314]

+1 To declaritively wrap a windows program with all the relevant wine settings would be amazing.

[cleverca22]

that does sound like it would be useful, but similar past issues&PR's have been shot down, #13625 #10006 #7597 #10981

[joepie91]

@cleverca22 To emphasize my previous statement:

I should note that I don't necessarily need this to be merged into nixpkgs; hence my uncertainty where to file this issue.

It's not so much a proposal for modifying nixpkgs to include this functionality, it's more of a question on how to approach it from an expression-writing point of view. I'll have a look at those PRs to understand the implementation, though - however, they don't seem to bring in any non-standard WINE versions or configurations from a quick glance.

[joelmo]

I would use buildEnv, you pass several different environments and makes symlinks to the passed derivations. But think about the registry, every wineprefix have it's own so one would probably need to merge these. You could create two different prefixs and install different apps to them to then see if any other files differs.

[Ericson2314]

I wasn't aware of that controversy, wow. Regardless, I see no issue with adding the infrastructure to declaratively create wine prefixes, as opposed to packaging of proprietary software with that infrastructure.

A good start would to make a branch with those rejected PRs, refactor out some common boilerplate, and get that merged but not the rejected packages.

[Profpatsch]

I think the question was answered, feel free to reopen otherwise.

[lopsided98]

I was looking into implementing something like this, but I think it is infeasible in the general case. Most Linux software can separate its installation location from its configuration/data location, but this is not the case for most older Windows applications. They store configuration in their installation directory, and expect to be able to modify the registry at install and run time. Modern Windows software should store mutable data in AppData, but wine does not appear to provide a way to store this outside of the prefix, and you still have the problem of the registry.

The only way I could see of making declarative Wine prefixes work would be to use a filesystem overlay over the installation prefix in the Nix store to store mutable data. Windows actually does something similar to maintain compatibility with old software, but I think this is a lot of complexity for relatively little gain.

[deliciouslytyped]

Currently unusable WIP implementation experiment https://github.com/deliciouslytyped/nix-winnix
I'd have posted it earlier but I'm not sure I knew of this issue.