How to handle application configuration

[AlexAxthelm]

Come to a consensus on how we as a team would like to handle application configuration.

Some methods (all live in our current repos)

• A series of Sys.getenv() calls (often used with docker-compose.yml or azure-deploy.json)
• Passing in a JSON file (jsonlite)
• Passing in a YAML file (config)
• defining behavior in an .env file (dotenv)
• defining behavior in an .env file (base::readRenviron())

While there is some space for variation, having a general strategy team-wide would help make onboarding to a new project/codebase easier.

[cjyetman]

Generally speaking, I strongly dislike hidden files that contain important stuff that change how things work, which rules out 1, 4, and 5 for me. JSON and YAML work for me, but I find JSON significantly easier to make mistakes with.

[jdhoffa]

I am not sure if this would fit in the practices repo...

Thinking aloud here:
The point of this repo is to document and track the social heuristics (e.g. what does it mean to be a maintainer, what are good git practices, how can you write an effective PR, how to do PR review, what is a code "lifecycle", how can we best communicate the status/ purpose of a repository (e.g. pacta.* vs workflow.* naming discussion)

This feels like a more prescriptive "you must use either .yml or .json, which is something I'm not as concerned about. I think that's a useful discussion to have, but I think it's too prescriptive to try to enforce that here...

What do you both think?

[AlexAxthelm]

I think practices should cover coding guidance, since that is a social contract as well. Suggestions on common patterns are just as much a part of a style guide as details about indentation.

I don't think that this topic is supposed to be enforced, but more of a "here is a sensible default way to do this, an if you want to do something different, please document why you're breaking the pattern"

[cjyetman]

I think it's sensible to discuss here, but also not a fan of strongly prescriptive rules.

[jdhoffa]

I disagree with @AlexAxthelm, for now, based on the following two principles:

• I won't put prescriptive rules in this repo (even "heuristic" rules have already proven to be incredibly difficult to agree upon, prescriptive rules are a whole new debate that: a) I don't have the energy to start, and b) I am not convinced are useful for our team right now)
• Adding a "non-prescriptive" rule about this immediately enters us into a gray area if we merge "a suggestion that we think everyone should use .json but we won't enforce it and you can use .yml if you want, but we think you should use .json...". That is a gray area I do not believe should be documented in practices.

I'm happy to leave this issue open if you wish to use it to have the discussion (as it is still interesting), and even happy to align on how we want to do things "for now". I do recognize that this is a good conversation and don't intend to do anything that would block the discussion itself, but I don't intend to take any action on this regarding any actual content in the practices repo.

Happy to re-evaluate that decision once this repository is a bit more mature, and its purpose is a bit more well-defined (and also once we have some of the less contentious and less prescriptive practices agreed on).