basak / glacier-cli

Command-line interface to Amazon Glacier

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

`glacier` binary is in conflict with boto's `glacier` binary

shazow opened this issue · comments

boto is a requirement to run glacier-cli, but when boto is installed, boto creates a glacier script.

https://github.com/boto/boto/blob/develop/setup.py#L59

In the README examples, glacier.py is referred to as just glacier and in this case it won't work because boto will override it.

Right. I filed boto/boto#1548, but that's as far as I got. It seems a bit onerous to use a different name in this project since it's designed for direct command line use and users will have to deal with a different/longer name constantly, particularly because the glacier command supplied by boto isn't particularly useful. Suggestions appreciated.

Can we rename glacier.py to glacier-cli.py?

It seems a bit onerous to use a different name in this project since it's designed for direct command line use and users will have to deal with a different/longer name constantly, particularly because the glacier command supplied by boto isn't particularly useful.

😕 There is no enigma here. Boto's package came first, however I will suggest a two ideas to break this "stalemate":

  • Convince the boto maintainers to integrate your code into boto, and bring you on board. This way everybody is happy: you (minimal work necessary), your community (I can install your package from pypi), and boto is too (there is some discussion that their utility isn't very useful).
  • Change your name. glacier-cli is your repository name after all, so maybe it could work? Or maybe glcr?

I like glcr. But the name of the script in the repo is kind of irrelevant; so long as the installation method is simply ln -s the user is free to call it whatever they want. Unfortunately that doesn't work for git-annex, so I requested that git-annex should allow the path to be configurable.

commented

I like glcr. I hadn't consider that before and missed it in winny-'s, sorry. And this has gone unresolved for long enough. Provided the name's not already taken (someone please check the Debian archive or something), I'll be happy to accept pull requests renaming the recommended name, using that in a future setup.py and in packaging, etc, if everyone agrees. One requirement - first I'd like git-annex to be updated to use that name first if available, so there is no period when it is broken.

OK cool. But like I said, I don't think git-annex should be hardcoding the executable name anyway.

commented

I don't think git-annex should be hardcoding the executable name anyway.

I have no issue with that. But we should have a single well-known name that everything that expects the "glacier-cli interface" defaults to.

Totally agree :)

first I'd like git-annex to be updated to use that name first if available, so there is no period when it is broken

It doesn't matter which of the two is updated first - there will be an inevitable period of breakage.

git-annex will not be making the name of the program configurable. Pick a name and I'll use it.

It doesn't matter which of the two is updated first - there will be an inevitable period of breakage.

You can have symlink one to the other during transition period (I would recommend that).