# API of \`verdi computer\` and \`verdi code\` **URL:** \ **Category:** Developer\ **Created:** [March 1, 2024, 10:11am UTC](https://aiida.discourse.group/t/api-of-verdi-computer-and-verdi-code/315 "2024-03-01T10:11:23Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![geiger\_j](https://yyz2.discourse-cdn.com/free1/user_avatar/aiida.discourse.group/geiger_j/32/57_2.png) [@geiger\_j](https://aiida.discourse.group/u/geiger_j)\ **Post date:** [March 1, 2024, 10:11am UTC](https://aiida.discourse.group/t/api-of-verdi-computer-and-verdi-code/315/1 "2024-03-01T10:11:23Z")
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 ` `verdi code setup --config ` 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 -H/--hostname ...` etc. ---
**Author:** ![sphuber](https://yyz2.discourse-cdn.com/free1/user_avatar/aiida.discourse.group/sphuber/32/6_2.png) [@sphuber](https://aiida.discourse.group/u/sphuber)\ **Post date:** [March 1, 2024, 11:08am UTC](https://aiida.discourse.group/t/api-of-verdi-computer-and-verdi-code/315/2 "2024-03-01T11:08:23Z")
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. ---
**Author:** ![geiger\_j](https://yyz2.discourse-cdn.com/free1/user_avatar/aiida.discourse.group/geiger_j/32/57_2.png) [@geiger\_j](https://aiida.discourse.group/u/geiger_j)\ **Post date:** [March 5, 2024, 8:43am UTC](https://aiida.discourse.group/t/api-of-verdi-computer-and-verdi-code/315/3 "2024-03-05T08:43:52Z")
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!