I talked to Kees.

<kees> I think pitti's last comment is on-target: as long as there is _some_ way to do file-based credentials, that's fine.
<kees> I don't think you need to be strictly "backward compatible", though.
<leonardr> how bad would it be if we stopped using keyring and went back to a single unencrypted credential file?
<kees> it'd be kind of sad, given all the work put into making the keyring work. I don't think that code should be lost (why can't there be two ways to auth?)
<leonardr> in that case, do you agree with me that you should have to do something special to create an unecrypted credential file?
<leonardr> ie. it should never be created in normal usage, only by someone who knows that's what they're doing?
<kees> yeah, it's no worse that the current situation where you need a browser to create the cred file the first time. that would just change the process a little
<kees> as long as the cronjob use case is handled in some way, it's fine, IMO.

Here's my revised proposal:

1. launchpadlib looks for credentials in this order:

a) unencrypted in the path designated by credentials_file
b) unencryped in ~/.cache/launchpadlib/[host].credential
c) encrypted in the order determined by python-keyring

Alternative:
a) unencryped in ~/.cache/launchpadlib/[host].credential
b) encrypted in the order determined by python-keyring.

I would like to get rid of credentials_file because IMO its legitimate uses are outnumbered by its sketchy uses, but I'm OK with keeping it.

2. A script launchpadlib/bin/create_unencrypted_launchpad_credential lets you create a desktop-wide integration token for *any* computer name. If you want to run launchpadlib cronjobs on your computer, you run this script.

$ python create_unencrypted_launchpad_credential --instance production
[browser open]
I've written an unencrypted credential for "mycomputer" to "/home/leonardr/.cache/launchpadlib/api.launchpad.net.credential".
You can now run cronjobs that use launchpadlib.

If you want to run launchpadlib cronjobs on some other computer, you run this script and scp the credential over.

$ python create_unencrypted_launchpad_credential --instance production --hostname "myothercomputer" --output_file foreign.credential
[browser open]
I've written an unencrypted credential for "myothercomputer" to "foreign.credential".
If you want launchpadlib running on "myothercomputer" to pick up this credential automatically, scp this file to  "~/.cache/launchpadlib/api.launchpad.net.credential".

$ scp foreign.credential myothercomputer:.cache/launchpadlib/api.launchpad.net.credential

Analysis:

1. If we keep credentials_file, your existing scripts that use credentials_file will continue to work.

2. If we eliminate credentials_file, you will need to know to copy the auth file into ~/.cache/launchpadlib/[host].credential instead of into /tmp/auth. But you can use your existing credential file.

3. Someone who is just starting out and wants to run cronjobs on their personal computer, can run create_unencrypted_launchpad_credential. Someone who wants to run cronjobs on some other computer can use create_unencrypted_launchpad_credential and scp the credential.

4. Do we forsee a future in which the average Ubuntu user has launchpadlib cronjobs running on their system? If so, we should either get rid of the keyring and go to a single unencrypted credential for everything, or we should investigate one of the esoteric ways of accessing the GNOME Keyring from outside the X session (this does appear to be possible--it's what showed up when I initially searched for solutions to this problem).