Deprecate boto-rsync in favor of awscli?

[seedifferently]

The Python team at AWS has been working hard on a boto-based CLI project for their cloud services. Among the tools included is an interface for S3 which duplicates (and in many ways supersedes) most of the functionality provided by boto-rsync.

https://github.com/aws/aws-cli
http://docs.aws.amazon.com/cli/latest/reference/s3/index.html

Unless anybody sees a good reason not to, I'll probably deprecate this project in favor of awscli. They have more resources at their disposal for maintenance, not to mention the fact that it's an "official" tool provided by the AWS team.

Please discuss here if you feel otherwise.

[felixcheruiyot]

Quick question!
Can you perform incremental backup with awscli tool? I think that is what makes boto_rsync powerful.

[felixcheruiyot]

My biggest concern is it seems the owner is not supporting this project anymore. We have some issues though old, I feel they are important and should be solved.

[seedifferently]

@felixcheruiyot Thanks for your input.

My main reason for not giving this project that much attention (apart from time) is that I'm just not that happy with its code layout and quality. It was originally a quick hack of boto's s3put script (https://github.com/boto/boto/blob/develop/bin/s3put) to add some rsync-like features, and although it managed to gain some popularity (and I was initially able to add a few of the requested features) it wasn't long until other projects required too much of my attention to be able to maintain this in the way I'd like to.

To do this project justice, I'd really want to refactor it to have a more "object oriented" structure and probably re-base it on top of "botocore" (https://botocore.readthedocs.org/en/latest/) much like awscli does so that we can get a unified Python 2/3 codebase (thus addressing any unicode issues, which are one of the biggest requests). However, this brings up a few more issues since things like Google Storage might not be supported with botocore (so that's a bit of a catch 22), not to mention the fact that I'd then be pretty much making a 1:1 copy of the awscli sync command.

So, this is what has led me to the thought of deprecation. awscli seems to me like a satisfactory "upgrade path", and since it's an official Amazon project I suspect it will receive much better support and attention.

However, I am still open to ideas for keeping this project alive...I just need a reason to justify a) value beyond the scope of awscli sync, and b) the time it would take to refactor.

[felixcheruiyot]

I find no need to refactor and do an exact copy of awscli. Our needs might sometime be different but sometime we have a common goal. If it can be built better i.e good code quality so that anyone can extended and be a one stop shop by integrating incremental multiple backup providers in python, just the way you did with Google Storage.

You can build the new code on top of awscli like a wrapper and integrate google storage and others. The advantage will be one api, multiple providers.

Code quality should be good so that anyone can fork and contribute.

What do you think?

[howardroark]

If I may weigh in here... I would say that a worth while endeavour may be a simple cli sync util that works for OpenStack Swift. HP just committed in the range of a billion dollars to the OpenStack project. I foresee a lot of new cloud infrastructure propping up over the next few years that runs OpenStack.

It is a great opportunity for developing nations or anyone who can make the investment to build up new infrastructure.

[tomasdev]

It was a fun ride. 👍 for helping all these years. I just came to raise a bug but aws-cli solved it.