Support selecting the active AiiDA profile via an environment variable

[hujay2019]

Is your feature request related to a problem? Please describe

Working with different AiiDA profiles in multiple terminals is inconvenient, because every verdi command needs to specify the profile explicitly with -p/--profile.

Describe the solution you'd like

Add support for selecting the active profile through an environment variable, for example AIIDA_PROFILE.

This would allow each terminal to set the profile once:

# Terminal 1
export AIIDA_PROFILE=project_a
verdi status

# Terminal 2
export AIIDA_PROFILE=project_b
verdi status

[mbercx]

Thanks @hujay2019! Interesting suggestion. I assuming you already know about verdi profile set-default?

❮ verdi profile set-default --help
Usage: verdi profile set-default [OPTIONS] PROFILE

  Set a profile as the default profile.

Options:
  -v, --verbosity [notset|debug|info|report|warning|error|critical]
                                  Set the verbosity of the output.
  -h, --help                      Show this message and exit.

Having an environment variable for profile discovery might also be useful, if it doesn't already exist. But we'd have to compare the added value vs complexity.

Side note: We have also thought about git-like discovery of profiles, which I support. NOTE: this is not git-like discovery of AiiDA instances, which I am highly against, see this long essay on the topic. @giovannipizzi wanted me to follow up on that relatively soon, which I will probably do in an AEP.

[hujay2019]

Hi @mbercx, thanks for the quick response!

Yes, I’m aware of verdi profile set-default, and I agree that it is useful for setting a global default profile.

However, I don’t think it fully solves this use case. The problem is that the default profile is global state. For example, suppose Terminal 1 is running a bash monitoring loop that repeatedly calls verdi commands using project_a. If I then switch to Terminal 2 and run verdi profile set-default project_b, the commands still running in Terminal 1 may unexpectedly start using project_b instead, which can cause the monitoring task to fail or operate on the wrong profile.

My current workaround is to wrap verdi with a small script in ~/bin/verdi that injects --profile based on an environment variable:

#!/usr/bin/env bash

if [ ! -e "${REAL_VERDI_PATH:-}" ]; then
    echo "Error: REAL_VERDI_PATH is not set or does not exist: ${REAL_VERDI_PATH:-<empty>}" >&2
    exit 1
fi

if [ -z "${AIIDA_PROFILE:-}" ]; then
    PROFILE_ARGS=()
else
    PROFILE_ARGS=(--profile "$AIIDA_PROFILE")
fi

exec "$REAL_VERDI_PATH" "${PROFILE_ARGS[@]}" "$@"

Then I can use different profiles conveniently in different terminals:

# Terminal 1
export PATH=~/bin:$PATH
export REAL_VERDI_PATH=path/to/aiida/verdi/command
export AIIDA_PROFILE=project_a
verdi status  # this will use profile project_a

# Terminal 2
export PATH=~/bin:$PATH
export REAL_VERDI_PATH=path/to/aiida/verdi/command
export AIIDA_PROFILE=project_b
verdi status  # this will use profile project_b

This works well for my work, but it would be much cleaner and less fragile if this behavior were supported directly by AiiDA.

[mbercx]

Right, of course. Thanks for the clear explanation. I can definitely see the use case, and the env variable is an easy and elegant solution. We should look into wiring this into the profile discovery logic. I don't think it should be that difficult, but those are typically famous last words. ^^

I'll add it to the v2.9 project, so we don't lose track of it in the sea of issues and prioritise.