WIP - [FEATURE] Adapting the CLI interface

[rcannood]

Feature summary

WIP: I'm thinking (again) about how to restructure the commands

Global commands:

• viash check: Check whether Viash is installed properly and whether optional dependencies such as Docker / Nextflow / Podman / Apptainer are working (maybe not by default)

Project commands:

• viash build: What is now viash ns build, except that it also outputs the processed project config to target/.build.yaml
• viash test: What is now viash ns test
• viash validate: Check whether the _viash.yaml is formatted properly
• viash ls / viash list: List all components.
  • Has arguments to specify how detailed this information should be, e.g. only the component names, namespaces, paths, and which runners and engines this component has? or should this be a concatenation of all components?

TBD Project commands:

• viash get biobox: Fetch a certain release from Viash Hub?
• viash publish: Publish current package to Viash Hub?
• viash sync_resources: Sync test resources to local disk
• viash add <field> <value>: Add an entry to the project config

Component commands:

• viash run <path/to/config.vsh.yaml: Run component
  • Allow to run viash hub components as well
• viash test <path/to/config.vsh.yaml: Test component
• viash add <path/to/config.vsh.yaml `: Add an entry to a viash config, e.g.:
  • viash add dependency biobox@v0.3.1/arriba
• viash get biobox@v0.3.1/arriba --runner executable: fetch the executable from viash hub

(Can we omit the viash config ... part by assuming the command is component specific when a config is passed?)

Hidden commands:

• viash config inject <path/to/config.vsh.yaml: ...
• viash export ...

Feature description

Why is this feature beneficial?

Alternatives considered

Possible solution

Confirmation

• I have searched the existing issues to make sure this is not a duplicate request.
• I have provided clear and concise information about the feature.