Any plans for "tighter" Python integration?

There's a module for "linking" to python released last year. It depends on an rclone install and as far as I can tell all it really does is make pretty progress bars.

Not that I can think of any specific use for a Python module off the top of my head, all the rclone i/o is cli anyway. I'm just curious because I have a strategic interest in both rclone and Python.

Best

Joe

2 Likes

hi, me too, as my backup scripts are written in python. to run rclone, restic, 7zip, etc.

the script reads dictionaries, from .ini file,
to create environment parameters and feed that to subprocess.run
as i use mostly s3 and sftp, there is no need for rclone config file.
simple and reliable.

en_kdbx_wasabi.env={"RCLONE_CONFIG_EN_KDBX_WASABI_TYPE":"s3", "RCLONE_CONFIG_EN_KDBX_WASABI_PROVIDER":"Wasabi", "RCLONE_CONFIG_EN_KDBX_WASABI_ENDPOINT":"https://s3.us-east-2.wasabisys.com", "RCLONE_CONFIG_EN_KDBX_WASABI_ACCESS_KEY_ID":"redacted", "RCLONE_CONFIG_EN_KDBX_WASABI_SECRET_ACCESS_KEY":"redacted", "RCLONE_CONFIG_EN_KDBX_WASABI_NO_CHECK_BUCKET":"true"}
en_kdbx_wasabi.sse={"RCLONE_CONFIG_EN_KDBX_WASABI_SSE_CUSTOMER_ALGORITHM":"AES256", "RCLONE_CONFIG_EN_KDBX_WASABI_SSE_CUSTOMER_KEY":"redacted"}
en_kdbx_wasabi.mfa={"provider":"wasabi","aws_access_key_id":"redacted", "aws_secret_access_key":"redacted", "secret":"redacted", "serial_number":"arn:aws:iam::redacted:user/user.en.keepass", "duration_seconds":"900"}

It is not complete and is part of a larger package, but you can pull out my rclone rc interface and use that if you'd like. It basically manages an rclone rc run with different calls and a more standard interface.

I also have in there an rclone cli interface but I am moving away from that since it is so much less efficient.

I agree that a kind of API for Golang (since rClone is made in that language) would be welcome and then people could use the API in a DLL or other library type in other programming languages such as Python. I've heard it's possible for C, C++, Rust but not for Golang, although it probably should be since it's a non-interpreted language.

Here is a good start, I think

I made this interface for python which runs an in-memory API for rclone using a loadable library. It is quite low level but it should work well.

It would be great if the interface above could speak to an rclone rcd instead of using librclone and I see you've done that bit in your library @jwink3101 - maybe we should merge the two approaches.

This library should probably live on pypi so there is a definitive rcloneapi module.

1 Like

I am interested but I will need to find the time.

The challenge is, how full-featured should it be? If you look at mine, it has functions to make life easier around some calls (e.g. list()) but others, you'd have to make the direct call to the endpoint (which mine makes easy to do but you still need to look at rclone's docs) (e.g. operations/settier). My logic was that if I wanted it to be easy to remember and use, I wrote it directly.

One thing I did is wrote the tools to split an rclone path. That is nice because it appears (from empirical testing) that credentials are cached by the srcFs (or dstFS). So you can give it a tuple of (srcFs,srcRemote) or a string of remote:path/to/file and it will split the latter.

I think that getting the basics right would be the first step, so encapsulating everything rclone can do. So you can look at the API docs and have an easy way to do that with python. So something which encapsulates the _config, _filter and _async parameters too.

The lib should be able to then call that on an rcd (which it could start and manage like your lib does) or on a librclone.

Then higher level things could be built on top of that if required.

Yes the backends are cached by srcFs / dstFs and you should re-use these if at all possible for efficiency.

I am pretty green as a coder, but maybe I can help. What do you think?