Alternative way to specify Github tokens for private devbox plugins

[jasononeil]

What problem are you trying to solve?

The ability to use private Github repos for Devbox plugins was added in #1918, but requires the use of a GITHUB_TOKEN environment variable. I would like a different way to specify a Github token.

For extra context, we're hoping to use private devbox plugins with ~200 engineers, and would like to streamline the process of setting tokens. Some engineers likely already have a GITHUB_TOKEN environment variable that clashes with what devbox is requiring. Setting environment variables in a global way also likely requires modifying their shell files (eg ~/.zshrc) which is something we're hesitant to do. We already have a setup script we use to configure Devbox and related tooling on these machines, so would like a solution that we can reliably control programatically.

What solution would you like?

My preferred solution would be that the token is stored in a flat file in the user's home directory, similar to ~/.npmrc files. Preferably the file format is stable and easily readable/writeable by both humans and software.

Example ~/.devboxrc.json

{
    "github_token": "...."
}

(Note: npmrc supports a cascading config from system level to project level, that doesn't feel useful to me for this specific use case).

Alternatives you've considered

Other alternatives might include:

• Continuing to use an environment variable, but with a name that is less likely to conflict, eg DEVBOX_GITHUB_TOKEN

• Reading config from git config credential.helper or gh auth token (if they have gh installed). I suspect re-using a token the user created for something else will be problematic - we don't know if the token has appropriate permissions for this use case (too much permission, too little permission, expiry dates etc)

• We could have a per-project solution utilising .envrc files and direnv:

  # Export GITHUB_TOKEN in a `.devbox_global_env` script
  source_env_if_exists ~/.devbox_global_env
  
  # And only then load devbox
  eval "$(devbox generate direnv --print-envrc)"
  

  This solution doesn't require changes to devbox but would require us to update our .envrc files across many of our internal projects.

Other context

• Devbox may one day support private plugins from other git hosts, see Privately hosted Devbox Plugins on non-Github Git Servers #2048. We should make sure the choices here don't hinder that.