Boto implemented command line utility, overrides other utilities #1015

uskudnik opened this Issue Sep 25, 2012 · 4 comments


None yet

4 participants


Hey guys,

as it appears boto recently implemented it's own command line utility for glacier ( which started overriding my utility ( On a more philosophical level (I may be wrong here so do correct me if I am) I consider boto more of a library and as such didn't even expect you guys would like to have a command line utility and if such really is the case I would happily merge it into boto.

While I don't mind if boto wants to keep its current command line utility I would recommend a joint effort since we have a larger feature set and are (partially already, entirely in the future) using boto for the backend anyway.



I think it's useful to have these types of tools directly in boto. We've got a long history of producing tools for boto, and I generally think these tools are very useful to have all in one place.

If you're interested in helping to contribute to the glacier tool, I'm sure we'd be more then willing to incorporate your changes.


Oh, then its OK and I think I speak for all contributors when I say that we would love to get our code into boto, least of all because it would be exposed to the broadest number of users.

How would boto as a project like to approach this? I presume you want to wait with any incorporations until we migrate to pure boto-only code - at the moment we use our own code for calls to glacier, see

garnaat commented Sep 27, 2012

Hi -

I think there are two paths. If you would like it to be in the bin directory of the boto distribution, we should migrate it to use boto for the API calls, work out a strategy to merge the functionality with the existing Glacier CLI tool (I don't think we want two), and identify any external dependencies (hopefully none).

The alternative would be to make it a separate project under the boto organization. That's simpler but not as useful to you or the boto community.


boto, the project, and the AWS ecosystem have changed a lot since this issue was opened in Sept 2012. On one level, this question is pointing to higher level design decisions that are well established at this point. It seems to me that at this point it is very clear that all public resources in the AWS ecosystem may be address via the AWSCLI tool which then calls one or more AWS Service APIs. Boto also is calling these same AWS APIs.

Garnaat's approach seems right to me. If there is a code base that adds additional functionality - as a CLI tool - then that code should be a pull request to the AWS CLI tools codebase or a separate tool ( perhaps as the reference repo ).

Reviewing the github repo at a summary level, it seems to that that code base has quite a few issue and the response to pull request on the repo seem too slow or non-existant and calls out for a maintainer, perhaps. Thus, this specific issue it seems may be too old and boto's general design is pretty much a given, is it not?

Also, without any real activity on this thread since 2012, there does not appear to be enough "pain" or benefit to study this thread and related code base further. If this assessment is incorrect, please let us know and I will look a bit further.

Please point to the specific feature that are desired to be merged into boto and any "important" bugs. Also, it would seem that one would have to also check whether boto3 and/or botocore address any of the specfic features already.

Thus, I believe we should close this issue and let any features that the amazon-glacier-cmd-interface repo might add be proposed as a specific pull request from that project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment