As table setting, I don’t think of Deja Dup as a duplicity frontend but rather a backup program that just happens to use duplicity. Tomorrow it might switch to borg or dumping everything to a single file if those meet our needs more.
So my initial gut reaction to requests for new duplicity backends is that they are an abstraction break we have to maintain, rather than the natural feature gap the requester is probably thinking of.
Deja Dup also has a mission statement that aims squarely at ease of use and converting people that don’t have a backup to people that do. So I tend to consider that if a user needs something more complex than Deja Dup, they should use one of our alternatives rather than Deja Dup growing that complexity.
But let’s think about how we might expose things a bit if we wanted to support folks that miss a particular backend.
Rough Needs for a Backend
- Ability to get free & total size on backend - needed so we know if we have to make room for new backups
- Ability to login and save credentials, if needed. If it’s not just a simple username/password setup, we need to be able to give duplicity something it can use to authenticate itself. Each duplicity backend varies in what it will need from us and may even try to do console interactions.
- Passing arguments, environment variables, and a url to duplicity.
Do we need a plugin?
Ideally we could get away with something lighter weight than bundled code. Depending on the duplicity backend, we could get away with just allowing users to pass arguments and such to duplicity via gsettings keys or similar.
Some downsides though:
- it only works for some duplicity backends
- won’t let us manage backup space (and thus will eventually give some error messages)
- we can’t make the experience nicer at all (like interpreting backend-specific error messages better or the like)
- no ability to “maintain” it, as new Deja Dup features appear (like maybe “keep backup size less than $maximum” or maybe we migrate to borg and have to stop supporting this method)
- “secret” methods like gsettings keys gets a little annoying these days because flatpaks keep them in a keyfile out of the normal way. And snaps don’t install the gschema in a global spot. So normal tools even an advanced user would try might not be able to tweak the settings
- this approach is only really useful for people comfortable with the duplicity command line, in which case, they can just make a cron job and call it a day anyway
Plugins could be implemented via libpeas. Which makes the loading part easy anyway.
On my end, this means I’d probably need to put a fair bit more thought into the design and extension points of the backend api. And maybe create a way for the plugin to extend the preferences UI (or just do the json file approach you mention). Probably need to have plugins declare a minimum version of duplicity too.
On the plugin developer’s end, they’d need a way to distribute & update the plugin. Maybe just have folks download a Python file and forget about updating it?
And on the user’s end, they’d need to find and install it. And any dependencies the duplicity backend has (like the module for talking to B2 or whatever).
This gets a little weirder in the snap & flatpak worlds. While Deja Dup can likely load the files from the system even confined (since it needs wide read permissions anyway), getting the dependencies for the duplicity backend playing nice with the confined Python might be tricky. I’m thinking version mismatches I guess. Path issues could be solved with the right environment variables.
This is a lot more work, but this is already Deja Dup’s supported “extendable” backend.
If someone writes a gvfs backend for a service or protocol, then anyone can just use that directly as a Network Server.
And those can be plugins too I think?
So a plugin system seems possible. But would need a lot of thought. And distribution is a concern.
GVFS might be a good option? But that is non-trivial for sure. Though it does mean that everyone benefits, not just Deja Dup.
Thoughts on any of that?