Travis support?

[hadley]

Presumably using encrypted env vars. I think this is mostly just a convention (i.e. use env vars) and some documentation (where to enter them on the web api).

(Alternatively you might be able to automate the process of copying from the local key store using the travis api, but that's probably a job for another package)

[gaborcsardi]

Yes, if the user has a Travis PW in the keyring, then I can use that with the Travis API, but as you say, that's probably for an rtravis package (somebody started writing one not long ago afair). So rtravis could use keyring for this.

But I am not sure what you would need from keyring? Just docs?

The rtravis R package could also ask you for a token or pw, and then store it in the keyring, and reuse it later. (Similarly, any other package that needs credentials could do that, devtools, httr, etc.)

I am not sure what you mean by the encrypted env vars.

[hadley]

I'm thinking it would be nice if get_password("google") worked for you both locally and on travis (where gnome-keyring won't be available)

[gaborcsardi]

@hadley Wow, part of me is terrified of this idea. :) I definitely don't want to give Travis access to my google account.......

But I see now what you want. Hmmmm. It seems like a bit too much for this package. Maybe it could also go into an rtravis package. rtravis could provide an abstraction layer over keyring / encrypted env vars. It was @jeroenooms's package, btw: https://github.com/jeroenooms/travis

I think it makes sense to make keyring only deal with the key rings.

[hadley]

I get your point, but travis encrypted vars are implicitly a keyring, and it would be very little extra code.

[gaborcsardi]

@hadley Well, according to this argument, a lot of things are keyrings.

Maybe I should rename this package to oskeyring or something?

Anyway, I'll leave this open for now.