Handling default "EOInput" parameters

Start by tracing how EOInput defaults are represented and how the --eoap/-a option determines the generated CWL document location. Compare the two proposed policies: omit EOInput defaults from CWL or place them in a separate default payload file. Done means the chosen policy avoids location-dependent defaults while preserving direct notebook use and clearly defines relative-path handling.

The recently added Directory + STAC catalog based inputs (as required by the EOAP best practice) allows default values for the path to the input directories.

The default paths are either absolute paths in which case local filesystem information is baked into the CWL document, which is undesirable or relative paths which only work when the CWL document is placed in a certain position in the file system.

The latter case becomes apparent, when using the --eoap/-a option. The paths in the CWL will be relative to the parent directory of the notebook, not of the xcengine output path. Setting -a to any directory other than the notebook directory generates a CWL document with defaults that do not work until the CWL document is moved.

Here are two options to remedy the problem:

Option 1: Don't allow defaults for EOInputs

There is no obvious way to set default input directories in way that still works when CWL files are shared. As EOAPs are meant to be shared and moved around, it may be a good idea to not have broken default paths but disallow defaults for these inputs entirely.

It would make sense to still be able assign Paths in the notebook (so it can be used without xcengine) but ignore the defaults when generating CWL.

This can already be achieved by setting "EOInput" parameters to objects of type pathlib.Path. However, this is an unintended side-effect and not a dedicated feature. Furthermore, when running the notebook as an EOAP, the paths will be set with values of type str, which may be surprising to the user.

Option 2: Add defaults to a default payload file instead of the CWL itself

An option to keep defaults working would be to set the input defaults not in the CWL but in a default parameter file (CWL input file) with some standard name that is easy to find for users.

The input file is not required to be shareable, so there is no problem linking it to the local file system state. However, we would still need to decide which directory to use as the basis for relative paths or convert paths to absolute paths.

For relative paths, the CWL standard clarifies at least for Files, that a relative File path must be "relative to the [...] document it appears in", which in this case is the input file.

https://www.commonwl.org/v1.2/CommandLineTool.html#File

The value of location may also be a relative reference, in which case it must be resolved relative to the IRI of the document it appears in. Alternately to location, implementations must also accept the path property on File, which must be a filesystem path available on the same host as the CWL runner (for inputs) or the runtime environment of a command line tool execution (for command line tool outputs).

For Directory inputs, the wording is less clear.

Using absolute paths may be the best solution, the file is generated anyway so managing absolute paths is not that much of an inconvenience for the user. They may replace the path with relative path for testing if they wish.