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

basak / glacier-cli

Command-line interface to Amazon Glacier

Other

617 stars 54 forks source link

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

Open shazow opened 11 years ago

shazow commented 11 years ago

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.

basak commented 11 years ago

Right. I filed https://github.com/boto/boto/issues/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.

xsuchy commented 10 years ago

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

winny- commented 10 years ago

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.

:confused: 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?

aspiers commented 9 years ago

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.

basak commented 9 years ago

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.

aspiers commented 9 years ago

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

basak commented 9 years ago

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.

aspiers commented 9 years ago

Totally agree :)

aspiers commented 9 years ago

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.

joeyh commented 9 years ago

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

xsuchy commented 9 years ago

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).