[Request] Support Lutris scripts

[TheEvilSkeleton]

Is your feature request related to a problem? Please describe. Lutris has a neat feature where you can directly install games using community maintained scripts: https://lutris.net/games.

Describe the solution you'd like I personally think that Bottles should support these scripts as well. I don't have any idea on the design yet.

Additional context A downside would be that there is no warranty. Some games are borked and/or outdated, so we can't confirm whether these scripts will work or not.

Second issue, we'll be trusting third party sources. There's "no" security to it. We'll have to recommend the user to read the scripts before running it.

[mirkobrombin]

I took a look at Lutris' scripts and found something to discuss.

First of all I see that they use winetricks for installing dependencies and Bottles does not support it (and it is not recommended to use it in Bottles), however this is not a problem as the name of the dependencies should be the same and for those that are not, a simple fallback name in our repository should be enough.

They use a set of tasks to replicate an installation and although this may seem at first sight similar to the actions used by Bottles, they are very different from each other structurally, it is therefore necessary to write a parser that understands and converts the tasks into actions.

The resources linked in the scripts have no hash so it is not possible to do a checksum verification (which in Bottles is mandatory and is a blocking factor). To manage these downloads it is necessary to modify the component manager and thus support downloads without checksums. But this causes other problems and I also have doubts: Lutris ignores corrupted downloads, or perhaps uses other methods such as reading the weight via the Content-Length header? I honestly doubt that's the case and think it just gets ignored if a file is compromised. However I think this is a blocking factor for an implementation.

I thought of a slightly different solution, namely a Lutris script to Bottles installer converter. In this case, the parser will only take care of bringing them to our syntax, leaving the maintainer the task of revising publishing them. In this way these will not be lutris scripts but real Bottles installers and therefore the component manager and installer manager structures must not change. In addition to this, the maintainer and we developers can actually provide support, which by supporting third-party scripts we cannot (and don't want to, I say it freely), as it can require much more effort, risking Bottles to be blamed for something it doesn't actually handle.

Moreover, this converter could be an external tool, perhaps on the Bottles website, or even be implemented in our editor (under development https://github.com/bottlesdevs/ide). Sorry for the wall text 😅, I hope everything is clear. I would really like to implement this but it is essential to understand which of the two ways is more convenient: support for third-party scripts without support or a tool that helps the conversion?

It would be useful to know the opinion of others on this as well. Also feel free to reach me on discord dm for a more deeply conversation about this.

[akdean]

as it can require much more effort, risking Bottles to be blamed for something it doesn't actually handle.

I think this is the main point which puts me off this idea, I think the Lutris setup can be a little clunky, and while it solves problems for a lot of people (and the developers clearly want to write good software,) I don't think coupling the two projects to this level would be good for Bottles in the long term, and it does risk that effect of the Bottles developers and maintainers being blamed when a Lutris script doesn't work.

Some sort of intermediary which converts existing Lutris scripts into Bottles could be a way to go, possibly, but I'm not sure it would benefit either side too much, other than providing a short-term adoption path for existing deployments.

I've had a look over several Lutris scripts and they vary wildly in the amount they do, I think it would be better to rewrite what exists into Bottles installers where required, which has the added benefit of retesting those scripts to see if all the 'workarounds' that are applied, are still needed.

[mirkobrombin]

I'ts a good point too, thanks for your point of view

[mirkobrombin]

Closing as not planned since Lutris scripts seems very different from the Bottles one and may cause a lot of problems.

[orowith2os]

To partially revive a dead issue, maybe Bottles could include some guide for rewriting Lutris scripts for use in Bottles? This would be useful, especially since Bottles can't utilize Lutris scripts.

Another thing: Does Bottles still not use winetricks? If so, why not include it? it's a fairly simple script, and if it were to conflict with how Bottles manages dependencies, it could be slightly modified to notify Bottles of any modifications, or Bottles could read the winetricks.log file in the appropriate wine prefix to be aware of what changes were made, and from where.

[mirkobrombin]

We already have a dedicate documentation for bottles scripting at https://maintainers.usebottles.com . I could write a dedicated guide.

No, we no longer use winetricks. I prefer not to reimplement it so as not to end up in chaos. The maintainers documentation explain how to contribute to our dependencies system which is appreciated.

One reason I don’t want to see winetricks in bottles is breaking standardization. Common and reproducible rules are indispensable for the survival of a project like Bottles, to prevent you from end up with a mountain of useless and impossible-to-maintain scripts. In addition, our manager is integrated with bottles and avoids annoying dialog boxes and unnecessary updates (in our context) of prefixes.

Winetricks is a great tool and it is right that platforms like Lutris depend on it but Bottles was created to make the experience as integrated and automated as possible, which is why it cannot be compatible with winetricks.