search

datalad / datalad-ria

Adds functionality for RIA stores to DataLad
http://datalad.org
Other
0 stars 1 forks source link

`create-sibling-ria --existing reconfigure --alias` does not reconfigure the alias #42

Open mih opened 2 years ago

mih commented 2 years ago 
datalad -C dist/packages/demo create-sibling-ria -s internal --alias pkg-demo --existing reconfigure ria+file:///tmp/wt/internal
[INFO   ] create siblings 'internal' and 'internal-storage' ... 
[WARNING] Alias 'pkg-demo' already exists in the RIA store, not adding an alias.
...

why ist that, when I instruct the command to "reconfigure"? Moreover, in my case, the alias would not even change (name or target), it warns nevertheless.

Bad UX IMHO.

adswa commented 2 years ago

I wonder what would be a better behavior in this case. Overwriting an existing alias seems dangerous because it could belong to a different dataset. Its not the same concept, but I think it also wouldn't match what e.g., git remote does when I'm asking to rename a remote to a name that is already taken:

adina@muninn in ~/repos/datalad on git:bf-6950
❱ git remote rename gh-adswa upstream
error: remote upstream already exists.

Not emitting a message might cause confusion if the alias exists but belongs to a different dataset. So maybe an additional check if the pre-existing alias belongs to the current dataset, and only warn if it belongs to a different one?

mih commented 2 years ago

From the POV of my present use case, I would have expected exactly that "overwriting an existing alias", because I am using aliases as a point (e.g. "current") to identifiy a dataset of interest that is changing over time.

Maybe the command could issue a warning that it was, in fact, replacing a previous alias, and report the replaced target, such that a user could go in and undo the action, if necessary,