.envrc

# NOTE:
# - This is the main entrypoint to secret management.
# - This file should not be edited often, the files it loads should be edited instead.
# - Most secrets should be added to other .env* files, take a look at the documentation:
#   https://github.com/iloveitaly/python-starter-template?tab=readme-ov-file#secrets

# ensures hard-to-find errors bubble up and fail the entire script
# https://direnv.net/man/direnv-stdlib.1.html#codestrictenv-ltcommandgt-code
strict_env

# if a developer does *not* want to use direnv, zsh, etc and stick with a non-standard setup
# then they can just set DIRENV_DISABLE=1 and manage their own environment locally
if [ "${DIRENV_DISABLE:-}" = 1 ]; then
  exit 0
fi

# https://github.com/direnv/direnv/pull/1352/files
# https://github.com/direnv/direnv/pull/1329
# https://github.com/direnv/direnv/wiki/Python#uv
layout_uv() {
  if [[ -d ".venv" ]]; then
    VIRTUAL_ENV="$(pwd)/.venv"
  fi

  if [[ -z ${VIRTUAL_ENV:-} || ! -d ${VIRTUAL_ENV:-} ]]; then
    log_status "No virtual environment exists. Executing \`uv venv\` to create one."
    uv venv
    VIRTUAL_ENV="$(pwd)/.venv"
  fi

  PATH_add "$VIRTUAL_ENV/bin"

  export UV_ACTIVE=1
  export VENV_ACTIVE=1
  export VIRTUAL_ENV
}

layout uv

# `inject` is much faster than individually sourcing keys with `op read`
# this function assumes `set -e` is enabled so if `op inject` fails, the script will exit.
# You may ask: why not just source the output of `op inject` directly?
# Without this wrapper, failures in `op inject` will not bubble up and fail the script/direnv call, which makes
# debugging much more challenging. It's easy for obscure error messages to get swallowed up and waste development time
# forgetting that this error path exists.
op_inject_source() {
  local tmpfile
  tmpfile=$(mktemp)

  # `inject` consumes stdin
  if ! op inject > "$tmpfile"; then
    just _banner_echo "1Password injection failed"
    cat >&2 << EOF
Make sure you're authenticated with 1Password, have access to referenced secrets, and are using valid secret references.
If you are using a service account token, this might need to be refreshed.

Some tips on how to resolve this issue:

- An expired token will result in a generic 403 error.
- Run \`just secrets_local-service-token\` to refresh your local token.
- If you need write access to 1P locally, run \`just secrets_write-service-token\`.
- Run \`just secrets_ci_grant-github-actions\` to refresh your CI token.
- When 1p fails to inject variables, you'll receive a obscure direnv env (pop_var_context) error.
- If you move a 1P entry out of a vault, this will cause a missing entry error.

EOF
    rm -f "$tmpfile"
    return 1
  fi

  source "$tmpfile"
  rm -f "$tmpfile"
}

# this is hack to allow us to render a specific .env file
# https://github.com/direnv/direnv/issues/1364
if [ -n "${RENDER_DIRENV:-}" ]; then
  for env_file in $RENDER_DIRENV; do
    source_env "$env_file"
  done
  exit 0
fi

# if env files are loaded which are in a different directory, $PWD will be changed to the enclosing directory
export ROOT_DIR="$PWD"

# .env should always exist, not contain secrets, and apply to all environments
source_env "env/all.sh"

# secrets or configuration to control `.env.shared` logic (such as a database connection hosts)
source_env_if_exists "env/all.local.sh"

# environment that only applies to local development (testing and development)
source_env "env/not_production.sh"
source_env_if_exists "env/not_production.local.sh"

# CI=true instructs direnv to load all test-specific environment variables
if [ -n "${CI:-}" ]; then
  source_env "env/test.sh"
  source_env_if_exists "env/test.local.sh"
else
  # unique setup for your local machine, allow overrides of common configuration, contain development secrets
  source_env "env/dev.sh"
  source_env_if_exists "env/dev.local.sh"
fi

# direnv does not have an easy way to source a .env.test file when in test mode. We could do this through pytest, etc
# This is harder than two different TEST_ variants for connection strings. I also like that for critical services (like DB)
# we very explicitly separate the test and production environments.
export TEST_DATABASE_NAME=test
export TEST_DATABASE_URL=${DATABASE_URL/\/development/\/${TEST_DATABASE_NAME}}
# NOTE redis databases (1,2,3,etc) are created on the fly, so don't worry about creating them beforehand
export TEST_REDIS_URL=${REDIS_URL/\/1/\/2}

env_vars_required PYTHON_ENV REDIS_URL DATABASE_URL SMTP_URL