You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when the scythe keyring, as set up by scythe_set_key is used for authentication, citation_search errors out when run in a parallel process because calls to the functions (eg: citation_search_scopus) that require keys have an interactive prompt that pops up asking for the password to unlock the key.
From the keyring docs: "Platforms typically have a default keyring, which is unlocked automatically when the user logs in. This keyring does not need to be unlocked explicitly." So, because we are using a separate keyring, it must be unlocked. I set my scythe keyring to never lock in my mac settings and keyring still always asks for a password. I've only been able to think of a couple ways to get around this, none of which are ideal.
use the default keyring as opposed to a special scythe keyring, which would remain unlocked (in theory...I haven't tested this)
have users send their keyring password in to the function call to non-interactively unlock the keyring using keyring_unlock (ouch)
allow for keys to be passed directly to the functions that require them. citation_search could interactively grabs the keys prior to the parallel call, then pass the secrets within the function body to the individual functions in parallel, thus moving the only interactive step to before the parallel call.
IF we decide to keep parallel functionality, I think I am leaning towards solution 3, but that would mean that we probably wouldn't want to export the citation_search_* functions since we don't want to encourage users to pass plain text keys in their function code. Even then, I'm not so sure its a good idea.
At this point, given that parallel processing doesn't speed us up much anyway, I think I'd prefer just removing it, period.
The text was updated successfully, but these errors were encountered:
Currently, when the scythe keyring, as set up by
scythe_set_key
is used for authentication,citation_search
errors out when run in a parallel process because calls to the functions (eg:citation_search_scopus
) that require keys have an interactive prompt that pops up asking for the password to unlock the key.From the keyring docs: "Platforms typically have a default keyring, which is unlocked automatically when the user logs in. This keyring does not need to be unlocked explicitly." So, because we are using a separate keyring, it must be unlocked. I set my scythe keyring to never lock in my mac settings and
keyring
still always asks for a password. I've only been able to think of a couple ways to get around this, none of which are ideal.keyring_unlock
(ouch)citation_search
could interactively grabs the keys prior to the parallel call, then pass the secrets within the function body to the individual functions in parallel, thus moving the only interactive step to before the parallel call.IF we decide to keep parallel functionality, I think I am leaning towards solution 3, but that would mean that we probably wouldn't want to export the citation_search_* functions since we don't want to encourage users to pass plain text keys in their function code. Even then, I'm not so sure its a good idea.
At this point, given that parallel processing doesn't speed us up much anyway, I think I'd prefer just removing it, period.
The text was updated successfully, but these errors were encountered: