Comment 8 for bug 1923727

I have straced this good call of the non-snapped git-ubuntu.
I see it reads the config you have expected (but it doesn't exist).

37311 4165256 0.000320
stat("/home/paelzer/.local/share/python_keyring/keyringrc.cfg",
0x7fff94243570) = -1 ENOENT (No such file or directory) <0.000024>

So if I haven't configured anything explicitly we might want to
understand which keyring implementation the non-snap execution will
select.
And from there derive what might be going wrong in the snapped execution.

I see it iterate over the keyring backends but there is no obvious "I
stop at keyring foo"

4165256 0.000073 openat(AT_FDCWD,
"/usr/lib/python3/dist-packages/keyring/backends/__pycache__/__init__.cpython-38.pyc",
O_RDONLY|O_CLOEXEC) = 3 <0.000020>
4165256 0.000060 openat(AT_FDCWD,
"/usr/lib/python3/dist-packages/keyring/backends",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 <0.000018>
4165256 0.000072 openat(AT_FDCWD,
"/usr/lib/python3/dist-packages/keyring/backends/__pycache__/fail.cpython-38.pyc",
O_RDONLY|O_CLOEXEC) = 3 <0.000019>
4165256 0.000077 openat(AT_FDCWD,
"/usr/lib/python3/dist-packages/keyring/backends/__pycache__/kwallet.cpython-38.pyc",
O_RDONLY|O_CLOEXEC) = 3 <0.000021>
4165256 0.000074 openat(AT_FDCWD,
"/usr/lib/python3/dist-packages/keyring/backends/__pycache__/SecretService.cpython-38.pyc",
O_RDONLY|O_CLOEXEC) = 3 <0.000021>
4165256 0.000138 openat(AT_FDCWD,
"/usr/lib/python3/dist-packages/keyring/backends/__pycache__/Windows.cpython-38.pyc",
O_RDONLY|O_CLOEXEC) = 3 <0.000030>
4165256 0.000074 openat(AT_FDCWD,
"/usr/lib/python3/dist-packages/keyring/backends/__pycache__/chainer.cpython-38.pyc",
O_RDONLY|O_CLOEXEC) = 3 <0.000020>
4165256 0.000073 openat(AT_FDCWD,
"/usr/lib/python3/dist-packages/keyring/backends/__pycache__/OS_X.cpython-38.pyc",
O_RDONLY|O_CLOEXEC) = 3 <0.000020>
4165256 0.000073 openat(AT_FDCWD,
"/usr/lib/python3/dist-packages/keyring/backends/__pycache__/_OS_X_API.cpython-38.pyc",
O_RDONLY|O_CLOEXEC) = 3 <0.000020>

I inspected the different options that could be used and found that
the local execution reaches the gnome keystore.
Therein I have a password entry for service "lauchpadlib" username
"... something constricted out of my sytems ID and a string".
And the content is a B64 encoded token.

That perfectly matches what is stored in
src/launchpadlib/credentials.py by the function
KeyringCredentialStore.

If I delete that entry in the gnome keyring, then the next non-snapped
execution presents me the very same "do you want to create a kde
wallet" popup
Any other launchpadlib based python app on my system now behaves the same.

So we can assume that the snapped-git-ubuntu fails to reach the gnome keyrings.
I know we are a classic snap, but might there be something needed to
reach the dbus based gnome keyring?
(https://specifications.freedesktop.org/secret-service/latest/)

So we have actually two problems here:
1. with an LP-auth entry existing in the gnome-keyring non-snapped
git-ubuntu finds and uses it, but snapped git-ubuntu fails and
therefore falls back to #2
2. (my local setups problem) if a key isn't found it wants to create a
new kdewallet based storage instead of adding it to the existing and
active gnome-keyring

I'd only want you to look at #1, #2 is entirely my own fun ...