Python client implementation

[amotl]

Hi there,

thank you so much for rclone-openapi and rclone-sdk, we love the approach. Based on that, we were just starting to explore if there is any Python binding available already, in one way or another?

With kind regards,
Andreas.

References

• Rclone panodata/omniload#139

[FTCHD]

What are you guys trying to do, embed the rclone binary or connct to an existing rcd instance/daemon?

[amotl]

Hi @FTCHD,

thanks for your swift reply and apologies for our late answer. We are currently trying to enhance polyglot capabilities of omniload by adding more connectors and formats (e.g. panodata/omniload#236), and thought it would be a good idea to loop into Rclone in one way or another.

In this spirit, we started a bit of research per panodata/omniload#139, and finally landed here, adding our proposal. Indeed there are three or more approaches to integrate omniload with Rclone: a) omniload could shell out to an existing binary, b) it can connect to an existing rcd daemon, or c) it could try to embed the binary.

All options sound viable to me, depending on use case and designated shipping variant. I think all of them could be sensible integration options for omniload, as it tries to wrap around many kinds of data transfer payloads.

I think options a) and b) are already possible through existing Python libraries, so we may tackle them first in omniload. Option c) could be unlocked through a Python binding to the rclone-sdk from your pen, like mq-bridge-py is doing it for mq-bridge by @marcomq. A corresponding connector was recently merged into omniload:

• AMQP, MQTT, NATS, etc. panodata/omniload#111

In the same spirit, we were starting to think how cool a Python package would be that would be similarly convenient like rclone-bin-api, but based on rclone-sdk instead.

With kind regards,
Andreas.

[FTCHD]

Sounds cool!

So why not wrap the OpenAPI spec and create the Python wrapper yourselves as a community package?

[amotl]

Hi again.

So why not wrap the OpenAPI spec and create the Python wrapper?

Wrapping around the Rclone RC API using the OpenAPI spec is absolutely the right choice to start with and yields maximum flexibility for Python and other folks, because in this way, Rclone can be addressed both on local and remote systems equally well. We might start the project, but we are already maintaining so many other Python packages, so we first wanted to ask if you know about a relevant project already, or if you would have better leverage to present the idea to the Rclone community, possibly also on other channels.

I will certainly be able to lend a hand or two, or bootstrap the project into existence. In the long run however, it would be nice to see the project to be continued on rclone or rclone-contrib organizations in a shared maintainership, so it will not add up to the projects we are maintaining exclusively.

On the other hand, our conversation here might be picked up and spark someone else's interest already. 🙏

With kind regards,
Andreas.

NB: Any support from the community is welcome, please ping us if you think you could join the development of rclone-openapi-python in one way or another.