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