Hey people,
I don’t think this warrants an actual issue, but still wanted to note it somewhere: Currently, verdi code create is the recommended way to set up a code, with verdi code setup still present, but with a deprecation warning. On the other hand, for a computer, it’s verdi computer setup and afterwards verdi computer configure. All commands allow passing a yaml file via --config. I guess for computer, the set up is split into two steps as the paths diverge based on the selected transport plugin? As a completely new user, I think it would be very convenient to be able to run:
verdi computer setup --config <computer-file.yaml>
verdi code setup --config <code-file.yaml>
Where:
- Both commands ideally use the same word (
setup or create)
- The configuration files might possibly come from more senior members of the group that’s using AiiDA, where the new user just started, and/or the
aiida-resource-registry
- Without passing files via
--config, the normal setup process proceeds as usual with fields asked one by one, and/or specifying them with the relevant cli options, such as verdi computer setup -L/--label <foo> -H/--hostname <bar> ... etc.
1 Like
Hi Julian, I agree that the differences are not ideal from a UX perspective. Let me give a bit of historical and technical perspective to explain why it is like that currently.
First, why are there two commands verdi computer setup and verdi computer configure? The first command creates a Computer instance in the database. This takes a transport_type which is the entry point for the Transport plugin that it should use. Each Transport plugin requires additional information in order to connect: LocalTransport doesn’t need much, but the SshTransport needs the login information. This information is stored in an AuthInfo object. Each AuthInfo object is connected to a single Computer and User as it essentially stores the info necessary for a user to connect to that computer. So verdi computer setup creates the computer, and verdi computer configure creates the AuthInfo object.
Why not put these in a single command? Well, the problem is that the options that need to be specified for the AuthInfo depend on the transport type, but that will be defined by the user in the command. So it is impossible to create a command that has the right options based on another value.
Next point: why is there verdi code setup and verdi code create? The original command was verdi code setup to nicely line up with verdi computer setup. Originally there were already two types of code, they were called “local” and “remote”. They correspond to what is now called PortableCode and InstalledCode. The codes required different types of input and the verdi code setup hardcoded options for both. The Code class was also used for both types. This all led to confusing APIs and complex implementation having to switch between types based on some attributes or inputs.
To solve this, the Code class was redesigned (although it was kept for backwards compatibility) and the AbstractCode was created. Different code types now subclass this (PortalCode and InstalledCode for example) and they are registered with entry points. They define their model schema dynamically, which can then be used to build up the CLI commands to create instances dynamically. Again, for backwards compatibility reasons, we couldn’t just change verdi code setup, so I was forced to name it verdi code create. But now the commands are dynamic and if new code types are added (even in other plugin packages) they are automatically integrated in verdi code create.
With that information as background, if you still have suggestion on how to improve the current situation, those are always welcome. But backwards compatibility is usually the biggest barrier. We could rename these things more sensibly in the future but that would probably have to go in v3.
1 Like
Hi Sebastiaan, thanks for your detailed explanation of the technical background and the history behind. I assumed that it was for these reasons, and as I mentioned, I don’t think it’s too much of an issue. We can keep it in mind for v3. I’ll have a look and give it some thought, as well. Cheers!