Usability: Easy export-import cycle for codes and computers

[GeigerJ2]

(see discussion below)

[t-reents]

When we discussed this, my idea was that it should be somehow easy to kind of "duplicate" a profile in terms of configured codes and computers. This will facilitate both development (i.e., creating new profiles or virtual environments) and general usage.

I see two options:

• We implement a new command that takes care of both. You execute it and it will export both computers and codes. We should also add a corresponding method that is able to read those configurations and recreate the computers and codes
• The second option would be to simply add a -a option to verdi computer export and verdi code export, which will dump all of the computers/codes into a yaml file. In this case, one should also adapt the methods to setup/configure computers and codes to support multiple entries in a (nested) yaml that can be provided for the --config option

[GeigerJ2]

When we discussed this, my idea was that it should be somehow easy to kind of "duplicate" a profile in terms of configured codes and computers. This will facilitate both development (i.e., creating new profiles or virtual environments) and general usage.

I see two options:

• We implement a new command that takes care of both. You execute it and it will export both computers and codes. We should also add a corresponding method that is able to read those configurations and recreate the computers and codes

I also thought about having a new command that basically would create the aiida-project setup/[computers,codes] structure. However, I think it hinders discoverability if we add more and more different entry points. The idea of exporting all computers/codes in the profile via -a/--all is good. We can also expand the command to accept a list of identifiers to allow export of multiple (in that case, using default values, and could be in a subdir then).

• The second option would be to simply add a -a option to verdi computer export and verdi code export, which will dump all of the computers/codes into a yaml file. In this case, one should also adapt the methods to setup/configure computers and codes to support multiple entries in a (nested) yaml that can be provided for the --config option

Here, I thought rather about multiple yaml files, one for each computer/code, with default names (for simplicity) (verdi computer/code export now don't require custom output filename anymore, but can use the label to construct a default name). I recall from when trying to make codes from the resource registry compatible with aiida-core, due to the verification of the yaml file entries via some click callback mechanism, that it was quite difficult / annoying to modify the behavior there. Might be easier to allow supplying multiple files and wrapping the CLI implementation into a for-loop.

Ping @mbercx.

[t-reents]

However, I think it hinders discoverability if we add more and more different entry points.

Agree, I think this is really crucial that we ensure that people actually find these useful things :D

I recall from when trying to make codes from the resource registry compatible with aiida-core, due to the verification of the yaml file entries via some click callback mechanism, that it was quite difficult / annoying to modify the behavior there. Might be easier to allow supplying multiple files and wrapping the CLI implementation into a for-loop.

Also perfectly fine with me. It's probably also easier in case one only wants to reuse some of them