posit-dev / posit-dev/rsconnect-python
Make system keyring discoverable (or default) for rsconnect login
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 37
- Forks
- 28
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 7
Description
Problem
rsconnect login stores OAuth tokens in the system keyring only if the optional keyring package is installed, otherwise it falls back to a local chmod-600 file and prints:
Note: keyring not available; credentials stored in local file (chmod 600).
keyring is an optional extra (pyproject.toml: keyring = ["keyring>=23.0.0"]), added alongside the login/logout commands in #773. The reasoning for keeping it optional is sound: rsconnect-python frequently runs in headless/CI/container/server environments where there's no usable secret-service backend (especially on Linux, where keyring needs SecretService/dbus), and the file fallback works fine there.
But there's a discoverability gap: a workstation user who would benefit from the OS keychain has no way to learn that the feature exists or how to turn it on. The fallback message states that keyring is unavailable but not how to enable it. Most users will never find the [keyring] extra.
Proposals
In rough order of preference:
-
Make the fallback message actionable. Tell the user how to opt in, e.g.:
Note: keyring not available; credentials stored in local file (chmod 600). To store credentials in your system keychain instead, install the keyring extra: pip install 'rsconnect-python[keyring]'This is low-risk and directly answers "how would I know to use it?"
-
Document it in the
login/logouthelp text and the deploying/auth docs (the--helpforloginmentions the keyring but not the extra needed to enable it). -
Consider making
keyringa default dependency. Modernkeyringinstalls cleanly on all platforms without heavy system requirements; on a backend-less Linux host it simply has no usable backend, and the existing code already catches that (keyring_store_tokenreturnsFalseon any exception and falls back to the file). If install footprint is the only concern, the trade-off may now favor including it by default and letting the runtime fallback handle headless environments. Worth at least evaluating.
Acceptance
- A workstation user can discover and enable system-keychain credential storage without prior knowledge of the
[keyring]extra (at minimum via an actionable message and docs).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the keyring extra in pyproject.toml, then locate the login fallback message, login/logout help text, and deploying/auth documentation mentioned in the issue. Done means a workstation user can discover the extra and enable system-keychain storage, with the actionable message and documentation covering the supported path.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- cli, documentation
- Issue type
- Documentation
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100