Low-complexity but powerful importer/sources variants

[GeoffreyCoulaud]

Is your feature request related to a problem? Please describe.

When implementing sources that don't expose custom URL schemes (e.g. bottles:...) it is difficult to both

• Scan for games from various sources
• Specify which command to use depending on the source (citra-qt vs flatpak run org.citra-emu.Citra)

I fear that the solution will be a big spaghetti plate.
In the same function, there will be schema population, config parsing, game parsing and game building.

Describe the solution you'd like

A more robust system of sources from which to import, using inheritance.
In that case, defining a base generic source would be the "hard" work, and to add variants (native, flatpak, snap, in-steam...) there would only be a few lines to change, e.g. for the config location and game building.

My proposal is to extend the importers in this structure:

importers
    citra
        citra_importer.py          # Generic base citra importer
        native_citra_importer.py   # Specific variant with overrides
        flatpak_citra_importer.py  # Another one
    steam
        ...

In this way, the core logic for each importer is in the base class and any change in behaviour is specified in the derived classes.

Describe alternatives you've considered

• Accept that these functions would get huge and difficult to maintain
• Treat variants as different import sources

Additional context

This comes from the development of Gali that has a robust source system, made to be highly extendable.
Since I wrote that code, I'm surely biaised. However, I don't think this concern is invalid, and ultimately making Cartridges more robust and hackable is what we should tend to.

This is a major change, but actually not much needs to be done since all of the code is already there in Gali, the only thing to do is to adapt the source backend to generate games in the Cartridge format.
I'm willing to contribute this code if the proposed solution is accepted.
Duplicating code in two FOSS projects is counter-productive, I want Cartridges to be better than Gali!

Would also fix issues #28 #35 #37 as a side effect

[kra-mo]

Hi!
Thanks for the proposal.

Currently, Cartridges does not have a clearly defined way of importing games, other than setting variables and calling functions in a specific instance of a class. While this does make the code more messy, it also makes it more adaptive as any function or class can act as an importer as long as it calls the right functions and sets the right variables. The function itself can be asynchronous, it can run multiple times, etc.
As such, I don't think refactoring the current import sources would need to be a priority. For sources that have a url handler, I think one file and one function would be enough, but it doesn't really matter. Multiple files could work just as well and I would not be against copying code from Gali that's using that structure as importers themselves are mostly self-contained.
Regardless, I would like if we could talk this over on Discord sometime!