Proposed breaking changes to the data structures and interface for project management

[rcannood]

For Viash 1.0 I'm considering the following breaking changes:

---

Change format of project config (_viash.ya?ml) to align better with the parameters in viash ns:

Current format:

  source: src
  target: target
  config_mods: ".functionality.version := 0.4.0"

Proposed format:

  viash_version: 0.7.0
  project:
    src: src
    target: target
    config_mods: ".functionality.version := 0.4.0"
    parallel: true/false

---

Changing the behaviour of viash ns.

Attempt 1: Simply rename viash ns to viash proj or viash project

Pros:

• Clears up some confusion as to what viash ns is
• Can make a clear connection between viash proj and the _viash.yaml project file

Cons:

• Can become annoying to type out every time.

Attempt 2: Use viash build for multiple things.

Examples:

• viash build: build the project
• viash build <config>: build a single component
• Deprecate viash ns build
• viash test: test the project
• viash test <config>: test a single component
• Deprecate viash ns test

What to do with:

• viash ns list?
• viash ns exec?

Pros:

• Short hand notation, somewhat similar to quarto.

Cons:

• Behaviour of component changes depending on the command used

Attempt 3: Rename viash ns x to viash x and viash x to viash config x.

Examples:

• viash build: build the project
• viash config build <config>: build a single component
• Deprecate viash ns build
• viash test: test the project
• viash config test <config>: test a single component
• Deprecate viash ns test
• viash inspect: list all components
• viash config inspect: view a single component
• Deprecate viash ns list and viash config view
• viash exec: Apply command to components
• Deprecate viash ns exec

Pros:

• I think this is the cleanest solution by far

Cons:

• That's a lot of breaking changes

[tverbeiren]

That's a lot of breaking changes

🤔 It sure is!

I wonder... during (component) development, I use viash run ... a lot. For pipeline development, it's mostly viash ns ....

What I'm getting at:

Attempt 4: Viash supports a running mode.

In practice, we would have to add an optional argument --mode component|namespace|project (or variations on this). Backward compatibility can be guaranteed by setting the default mode to component and switching to project when viash ns ... is run.

If we could specify a default --mode in the _viash.yaml project config file (or by means of an environment variable), we could cover all the above use-cases while making the change a bit less 'breaking'. viash [--mode project] test would map to viash ns test for instance.

[rcannood]

Latest proposal:

Contents of _viash.yaml:

project:
  source: src
  target: target
  viash_version: 0.6.7
  config_mods: |
    .platforms[.type == 'docker'].target_registry := 'ghcr.io'
    .platforms[.type == 'docker'].target_image_source := 'https://github.com/openpipelines-bio/openpipeline'
    .platforms[.type == 'nextflow'].directives.tag := '$id'

functionality:
  version: dev
  organization: openpipelines-bio