Setting a credential name for create-sibling-gin fails

[mih]

I did not have a token configured, but I wanted to have it saved under a specific name once entered. That this not work:

I am not asked for a token at all, and it fails with:

Running: Dataset('/tmp/myproject').create_sibling_gin(reponame='myprojecttest', private=True, credential='github-mih')
create_sibling_gin(error): [unauthorized: None]

[bpoldrack]

Reproduced. Logging reads:

[DEBUG  ] FSBrowser has no handler for result from <class 'datalad.distributed.create_sibling_gin.CreateSiblingGin'>

However, this is too late in the game to be the relevant part here.

The stranger thing is, that it claims to have been succesful:

[DEBUG  ] GIN responded with <Response [201]> {'id': 4943, 'owner': {'id': 1552, 'username': 'bpoldrack', 'login': 'bpoldrack', 'full_name': 'Benjamin', 'email': 'benjaminpoldrack@gmail.com', 'avatar_url': 'https://secure.gravatar.com/avatar/8e929a6e60f16f50e7463f88aab26f40?d=identicon'}, 'name': 'Anothertestrepo', 'full_name': 'bpoldrack/Anothertestrepo', 'description': 'some default', 'private': True, 'fork': False, 'parent': None, 'empty': False, 'mirror': False, 'size': 0, 'html_url': 'https://gin.g-node.org/bpoldrack/Anothertestrepo', 'ssh_url': 'git@gin.g-node.org:/bpoldrack/Anothertestrepo.git', 'clone_url': 'git@gin.g-node.org:/bpoldrack/Anothertestrepo.git', 'website': '', 'stars_count': 0, 'forks_count': 0, 'watchers_count': 0, 'open_issues_count': 0, 'default_branch': '', 'created_at': '0001-01-01T00:00:00Z', 'updated_at': '0001-01-01T00:00:00Z', 'permissions': {'admin': True, 'push': True, 'pull': True}} 

Meanwhile datalad credentials doesn't have anything for GIN in my case. Wondering where the username even comes from.

So, it turns out, that the credential passed in my case is dataverse rather than the (not existing) one I specified in the widget. Hence, forget what I wrote above. While reproduced not being asked for a token and there's something strange going on in my case as well (since I got a 201 with no valid credentials) it's not the same as OP.

[bpoldrack]

@mih :

Did I get it right, that you do have credentials with that name set up before, just w/o token? If so, how did you achieve that? I can't get datalad credentials to list a credential w/o a secret.

[adswa]

If I interpret the description correctly, I've ran into this too. I frequently run something like 'create-sibling-* ... --credential brandnew" when I want to be able to enter a new credential (that I never set up in any way before). This works on the command line, but not in the gooey, when I just free-text write a new credential name in the credential field.

The terminal traceback reads

Traceback (most recent call last):
  File "/home/adina/repos/datalad-gooey/datalad_gooey/param_widgets.py", line 370, in _handle_input
    self.set(None if not choice else choice, set_in_widget=False)
  File "/home/adina/repos/datalad-gooey/datalad_gooey/param.py", line 163, in set
    val = self.get_constraint()(value) if value != _NoValue else value
  File "/home/adina/env/gooey/lib/python3.10/site-packages/datalad/support/constraints.py", line 302, in __call__
    raise ValueError("value is not one of %s" % (self._allowed,))
ValueError: value is not one of ('nitrc', 'hcp-s3', 'api.osf.io', 'xnat', 'hcp-db', 'figshare', 'dataverse-https://demo.dataverse.org/dataverse', None)

and the command log

Running: Dataset('/home/adina/ml-books').create_sibling_github(reponame='willfail')
create_sibling_github(error): [unauthorized: Bad credentials]

[bpoldrack]

Yes, part of that's because the widget does not pass on a value that was not in the list of existing choices. However, I'd consider this a somewhat separate issue.

There seems to be several underlying oddities.

1. datalad credentials doesn't list all known credentials to begin with. That is: If I set up a credential w/o a secret it's not being shown.
2. If do what @adswa also did (specifying a brandnew cred with Create-sibling-gin) via CLI, it will ask for a secret the first time. Entering some nonsense fails. But specifying the same creds again will then fail to authenticate w/o ever asking, suggesting it used the nonsense from before. However, those brandnew credentials are nowhere to be found (but apparently used).
3. Via CLI and such a call as in 2., I end up in datalad core's _set_request_header of create_sibling_ghlike, while it's supposed to be the patched version from datalad-next.

So, something's completely off (for me).

[bpoldrack]

I think most of the confusing mess described above is going to be addressed by https://github.com/datalad/datalad-next/pull/114

[adswa]

Since the linked PR was merged, I have given this another try, and I can't reproduce the problem anymore. A not-yet-known credential name causes an interactive query in a Dialog window, and it will successfully save this credential if it worked. Closing.