chrisjsewell/activate_aiida

a package to activate an aiida environment, from a yaml config file

activate_aiida's Issues

aiida_environment.yaml <> config.yaml ?

since there are anyhow plans to move the config.json to a config.yaml format in aiida-core aiidateam/aiida-core#2701 , it seems to me we should think a bit about how to distribute information between the two in order to avoid duplication of information.

mentioning @pzarabadip for info

check for profile existence fragile

the package currently checks for whether a profile is already configured by
https://github.com/chrisjsewell/activate_aiida/blob/master/bin/aiida-activate#L122

However, for an empty profile, e.g. the file path of the working directory is in the output of verdi profile list:

verdi profile list
Info: configuration folder: /work/test34/repo/.aiida
Warning: no profiles configured: run `verdi setup` to create one

It will therefore assume the profile exists, when the filepath contains the project name (which just happened to me when looking into the aiida/renkulab integration).

Not a big deal (I'll just name the profile differently)

decide package name

As mentioned here, it would be good to agree on the name for this package together with @sphuber and @giovannipizzi

Things to think about:

• should conda be in the name?
• should it be hosted under aiidateam?

specify user email & name on the fly

we have a use case on renkulab, where we would like to specify the user email and name on the fly (pulling it from environment variables).
Since the aiida_config.yaml is committed to the (template) repository, we cannot easily get user-specific information directly into the file.

I see at least three possible ways of supporting this:

1. add command line options (perhaps not ideal; we don't want to add command line options for everything)
2. process environment variables inside aiida_config.yaml, i.e. one could set email: "$AIIDA_USER_EMAIL" (perhaps also not ideal since we're mixing yaml with env vars)
3. take user, firstname and lastname from specific environment variables, if they are not specified in the aiida_config.yaml
   (e.g. AIIDA_USER_EMAIL, AIIDA_USER_FIRST_NAME, AIIDA_USER_LAST_NAME, AIIDA_USER_INSTITUTION)

To me the last option sounds most promising
@chrisjsewell what would you prefer?

separate out postgres/rabbitmq "activation"?

hi @chrisjsewell - I'm coming back to this package, with the purpose of using it as part of a "conda-only" install of AiiDA (which could, in principle, also work to install AiiDA directly on a compute cluster in cases where access to the cluster is locked down).

The idea being:

• you install miniconda
• you do conda install -c conda-forge aiida-core aiida-core.services aiida-activate.
  this installs an aiida-activate cli
• you do aiida-activate start-services (or similar) which starts postgres & rabbitmq (creating new postgresql DB if necessary)

The script might look for an existing PGDATA environment variable and try to place the DB there, otherwise in something like ~/.pgdata

Anything beyond that (setup of aiida profile, data import etc.) might be available through other commands but is entirely optional.

Does this sound like a good idea to you?
In essence, I guess this would simply be taking out some parts of the script the you've already written.