Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@Russell-Shean
Copy link

@Russell-Shean Russell-Shean commented Dec 19, 2025

Reasons for making this change

Historically R users have used the .Renviron file for storing environmental variables such as secrets, credentials, API keys etc. However, I believe there are several compelling reasons for adding .env to the .gitignore too:

  1. The dotenv R package was created to allow users to use .env instead of .Renviron. The package has a significant number of downloads. https://github.com/gaborcsardi/dotenv

  2. .env files are standard in many other programming languages. It wouldn't be that out of the unexpected to think R users might end up with an .env file because a python user on their team contributed files to the repo, the R user started programming in nodejs and is used to working with .env file, or a repo is in the process of being translated from a language that uses .env to R.

  3. LLMs are making programming accessible to people who may not have much previous experience handling credentials and security. One of the first steps many of these users have to do is store LLM provider API keys somewhere. I worry about a new R user adapting a python workflow or an R workflow that recommends using an .env file and then accidentally committing their LLM API keys to a public repo.

  4. I can't think of why an R user would create an .env file for any other reason other than storing credentials and environmental variables. If, for whatever reason, they need to commit an .env file, they can remove that part from the template, but I think the risk of accidentally exposing sensitive credentials justifies adding .env files to the template and not commenting it out by default.

Links to documentation supporting these rule changes

https://github.com/gaborcsardi/dotenv

If this is a new template

Link to application or project’s homepage: N/A

Merge and Approval Steps

  • Confirm that you've read the contribution guidelines and ensured your PR aligns
  • Ensure CI is passing
  • Get a review and Approval from one of the maintainers

Historically R users have used the .Renviron file for storing environmental variables such as secrets, credentials, API keys etc. However, I believe there are several compelling reasons for adding .env to the .gitignore too:

1. The dotenv R package was created to allow users to use .env instead of .Renviron. The package has a significant number of downloads.  https://github.com/gaborcsardi/dotenv 

2. .env files are standard in many other programming languages. It wouldn't be that out of the unexpected to think R users might end up with an .env file because a python user on their team contributed files to the repo, the R user started programming in nodejs and is used to working with .env file, or a repo is in the process of being translated from a language that uses .env to R. 

3. LLMs are making programming accessible to people who may not have much previous experience handling credentials and security. One of the first steps many of these users have to do is store LLM provider API keys somewhere. I worry about a new R user adapting a python workflow or an R workflow that recommends using an .env file and then accidentally committing their LLM API keys to a public repo. 

4. I can't think of why an R user would create an .env file for any other reason other than storing credentials and environmental variables. If, for whatever reason, they need to commit an .env file, they can remove that part from the template, but I think the risk of accidentally exposing sensitive credentials justifies adding .env files to the template and not commenting it out by default.
R: add `.env` to prevent accidentally exposing credentials
@Russell-Shean Russell-Shean requested a review from a team as a code owner December 19, 2025 11:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant