Ludusavi as a library crate

[JMBeresford]

What's your idea?

Hello! First, I'd like to thank the maintainers here for all of their hard work! Ludusavi is a fantastic tool and I greatly appreciate the value it provides. Now, I am curious to know if there has ever been previous discussion on publicly exposing certain modules within Ludusavi to be published as a library crate?

For context, I am the author of Retrom -- a selfhosted server+client game library management software. I am currently working on save game management for Retrom, and I have been curious about how/if I can leverage Ludusavi in that process, particularly for non-emulated/native games. I am hesitant to rely on interfacing w/ Ludusavi solely via its CLI as a child process for a handful of reasons -- which I can elaborate on, if desired. As such, and considering Retrom is also written in Rust, I was curious to hear the thoughts of the maintainers here on publishing Ludusavi as a library? I would be willing to assist with this effort as well, if it would help 🙂

Thanks again!

[mtkennerly]

Hi! I hadn't really considered this since I wasn't sure if there was interest, but I'm open to the idea. I'll need to think about the API, but it would probably be similar to how the CLI currently looks - is there any data/functionality missing there that you'd want for your use case?

I am hesitant to rely on interfacing w/ Ludusavi solely via its CLI as a child process for a handful of reasons -- which I can elaborate on, if desired.

I can imagine a few reasons (mainly packaging and performance), but I'd be interested to hear any specific reasons beyond that.

[JMBeresford]

@mtkennerly

it would probably be similar to how the CLI currently looks - is there any data/functionality missing there that you'd want for your use case

I presumed similarly -- I imagined something along the lines of being able to build CLI arguments and execute them just as if using the CLI.

As for my specific use case -- I am still deliberating on some design choices, but the most important pieces of functionality will be:

1. The ability to execute backup, restore, find as if from CLI 1a. Getting the output as its native deserialized Result type ( e.g. returning the Reporter from a call to backup )
2. The ability to compose resource::Config and resource::Manifest objects for use in the above -- i.e. allow the commands/modules in 1. to take a Config parameter rather than relying on a file

Some minimal example interface could look something like:

struct Ludusavi {
  config: Config;
  manifests: Vec<Manifest>;
}

impl Ludusavi {
  pub fn backup(&self, Subcommand::Backup) -> crate::Result<Reporter>
  
  // etc etc
}

I have not looked too deeply into how Ludusavi handles multiple manifests under the hood. A major part of my use case will be constructing a custom manifest for Retrom's managed library entries ( Retrom has a heavy focus on emulation ), however I certainly want to make use of the default manifest for the Steam games ( and GOG soon, and others in the future ) that Retrom tracks as well as any manually added native games. What implications are there, if any, that should be considered here?

I am likely going to want Retrom to handle the cloud synchronization of the backups natively, so any cloud functionality on the part of Ludusavi would not be strictly necessary for my use case.

I am hesitant to rely on interfacing w/ Ludusavi solely via its CLI as a child process for a handful of reasons -- which I can elaborate on, if desired.

I can imagine a few reasons (mainly packaging and performance), but I'd be interested to hear any specific reasons beyond that.

Certainly those, and also the type-safety and peace of mind that comes with using ludusavi as a library rather than (de-)serializing input and output schemas. Additionally, the question of "do I force the distribution of the ludusavi binary into the Retrom package for all my users, or demand they provide a path to their own" no longer matters 🙂

All this to say, I'm more than happy to use Ludusavi via the CLI API if necessary but was curious if a library option would be considered. Looking forward to hearing your thoughts!