REQ - Guide for using environment variables
Nobody has claimed this yet.
- #174 by @Photon101 — closed without merging
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 45/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- r
- Domain
- documentation
Research direction
Review the use cases in this issue and the related issue #86 before locating the repository's documentation structure. The guide should cover project or personal .Renviron files, Sys.getenv(), and when keyring or readLines() is more appropriate, with clear guidance for avoiding committed secrets. Done means the documented practices address the stated scenarios and alternatives.
Written by the indexing model from the issue text.
Description
Is your feature request related to a problem? Please describe.
Inspired by this question (and mainly @rmccreath 's response): @bevthewitch - Can PHS GItHub members view a private PHS GitHub repo?.
The issue of mostly shareable code containing small bits of confi / potentially confi info, e.g. an API key.
Describe what you'd like
A guide explaining and setting best practice for storing and using environment variables, e.g. using the .Renviron (project or personal as required), and Sys.getenv() to retrieve sensitive info at execution without having it verbatim in code and therefore commitable by version control.
Describe alternatives you've considered
Environment variables are a good solution, in certain cases, {keyring} may be better as it also provides encryption. Similarly, saving a text file to disk and using readLines() might also be appropriate for data that needs to be used by a few PHS staff.
Additional context
Somewhat related to #86 but has a different set of usecases.
- Dominant language
- No language data
- Stars
- 7
- Forks
- 5
- Avg merge
- 20h 45m
- Merged PRs (30d)
- 2
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing 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.
More from Public-Health-Scotland/technical-docs
-
REQ - Positron IDE guidancePossibly taken @johannajokio claimed this 6 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
REQ - guidance for managing Shiny app performancePossibly taken @rmccreath claimed this 63 days ago. Opennew doc
Public-Health-Scotland/technical-docs#175 · 1 assignee ·
-
BUG - Images not appearing on Knowledge BaseMay be free again @rmccreath claimed this 338 days ago, and no pull request is open. Openbug
Public-Health-Scotland/technical-docs#171 · 1 comment · 1 assignee ·
-
REQ - Add step-by-step guide on how to clear list of recent projects on the Posit Workbench homepageOpendoc maintenance posit environment
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
Public-Health-Scotland/technical-docs#170 · 1 comment ·
-
REQ - Move `2. Environment Specifications` into its own documentPossibly taken @terrymclaughlin claimed this 373 days ago. Opendoc maintenance
Public-Health-Scotland/technical-docs#168 · 1 reaction · 1 assignee ·
All issues in Public-Health-Scotland/technical-docs
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
NCAR/wrf_hydro_nwm_public#933 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
gpt-oss "Forcing a tool call" row no longer reproduces: tool_choice is now honoured on every surfaceOpen
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
aws-samples/sample-per-model-bedrock#840 ·
Maintainers usually reply within 1 day