PhoenicisOrg
POC: Read lutris installer
Is the Theme Hospital script related to Lutris at all?
Does it make sense to implement it like this? I mean if you have to implement a wrapper script anyways, you could directly implement a Phoenicis script. My idea was a bit different: implement something like CustomInstallerScript for Lutris. So there would be only one generic script. If you run it, you give it the slug and the rest is handled by the script.
Is the Theme Hospital script related to Lutris at all?
Nope, and it does not work at all. I had just forgotten to remove it.
Does it make sense to implement it like this? I mean if you have to implement a wrapper script anyways, you could directly implement a Phoenicis script. My idea was a bit different: implement something like CustomInstallerScript for Lutris. So there would be only one generic script. If you run it, you give it the slug and the rest is handled by the script.
The script sample is not important. It is just a way for us to test that the core script works correctly. Afterwards, we can directly implement a Repository in java to wrap all the scripts directly
Understood. Do you want to create a Lutris SteamScript, a Lutris UplayScript etc or only one Lutris Script?
Understood. Do you want to create Lutris SteamScript Lutris UplayScript etc or only one Lutris Script?
Maybe safer to start small. At the end, you always can write a LutrisGenericScript that will redirect to the right subscript.
You can also factorize some tools (like installer step reading) somewhere else if you want
In my opinion this sounds like a task for a converter.
This would be the easiest way to handle this.
In a nutshell, we can then provide a LutrisInstallerScript, which only takes a slug.
The approach would then be as followed:
- download the lutris script
- convert it to a Phoenicis script
- execute the converted Phoenicis script
I also think that the conversion shouldn't be implemented in JavaScript, because there are too many conversion cases in my opinion. If we did this in a single JavaScript file it would be quite long and hard to read.
That's true. I somehow feel a bit uncomfortable about the way the Lutris repository will be created from Java. I'm sure it will work but from our concept it should rather be in Javascript. Especially because the Java repository will need this particular scripts repository. That doesn't feel right for me.
I'm not sure that you need to retranslate everything. It's way easier than that. If you look at my MR, you'll see that the structure is basically here (and it works).
What needs to be done is to look-up all the kind of task we can have (there is a finite number because lutris scripts are descriptive and not imperative).
Look at this method, we need to make it a little more abstract.
LutrisWineSteamScript.prototype._evalInstallerStep = function (installerStep, wine, wizard) {
if (installerStep["task"] && installerStep["task"]["name"] === "winetricks") {
var verb = nstallerStep["task"]["app"];
// TODO
}
}
What we can do here is to "register" a list of adapter instances written in JS to LutrisWineSteamScript.
An adapter just have two methods: -String defineTaskName() -void execStep(wine, wizard)
Then, we just implement a few time this interface and we are good
That's true. I somehow feel a bit uncomfortable about the way the Lutris repository will be created from Java. I'm sure it will work but from our concept it should rather be in Javascript. Especially because the Java repository will need this particular scripts repository. That doesn't feel right for me.
It can be done on an other place like a small microservice hosted somewhere
@qparis it is not that easy I believe.
Lutris scripts can also contain an execute block, where you can basically do everything you want as I understand it, for example executing unzip. We would need to convert these too. When doing this we will also want to check, whether we have our own tool for the execution task. For example we want to call our unzip script and not the system tool.
Additionally there seem to be system variables, wine configuration variables and other things. I'm not sure how much effort it is to translate/convert these things.
@qparis it is not that easy I believe. Lutris scripts can also contain an
executeblock, where you can basically do everything you want as I understand it, for example executingunzip. We would need to convert these too. When doing this we will also want to check, whether we have our own tool for the execution task. For example we want to call ourunzipscript and not the system tool.
We can call the system tool as a "catch-all" backup, this is fine. Then, we can tune to optimize
Or we can implement a system of script decorators.
Or an automatic instancier
It would be nice if the Lutris support could work just like any other repository without special mechanisms. It's a bit similar like for engines: they also have a special mechanism to get their versions. I wonder if we could streamline all this. My vision would be that every entity in the repository is a first class citizen which can be used in a common way. Not sure if that will really be possible but maybe it helps you understand what I'm thinking about.
In your vision, is it possible to fetch inside a repository something that can help fetching other repositories?
Yes, why not. As long as this is not restricted to certain script types etc. I think it would be valid if e.g. Wine populates the repository with all available Wine versions (or in this case Lutris with all Lutris scripts).
We we find a good way to implement this, sure. Maybe we should discuss this in a separate issue?
Yes but I’d just like to ensure that @madoar is ok with the approach. Don’t make me wrong, Lutris support is just a pretext to challenge our architecture. If we manage to do it without too much effort, we can then do a repository for GOG, etc...
I'm not sure I understand what exactly you have in mind. I'm fine with providing support for lutris scripts. I'm just not sure how to do it best. In addition I think that we should watch out what we do on the JavaScript side, because JavaScript tends to become messy if the code gets too long and complex.
Yes, we could basically provide a naive script for each and every Steam app. We could reuse the apps tab implementation to install engines, provide all winetricks verbs... There are so many things possible.
Let's move this discussion to a new issue. @qparis can you open it? Then we can explain the idea in more detail.