One idea to make imports more intuitive

[cjllanwarne]

One thought I'd had on making imports a bit more intuitive is to allow an optional namespace field at the top of a WDL file like this:

version 1.X

namespace "bam_processing/workflows"

import "bam_processing/tasks/my_tool.wdl"

workflow xyz {
  call my_tool.tool_task { input: ... }
}

How does this help anyone? Well.... when it comes to importing one of the tricky things is to work out where import paths are relative to. Sometimes they should be "relative to where I'm running from", sometimes they should be "relative to where this WDL file is". At the moment this is left up to the engine and often the zip bundle submitted alongside the main workflow.

This suggestion is that if a WDL specifies a namespace, that allows the engine to resolve imports relative to "the directory you get if you go back to the base of the namespace". In other words if the WDL above is in a directory /path/to/bam_processing/workflows/xyz.wdl then the "base" is /path/to/ and the import can be resolved as path/to/bam_processing/tasks/my_tool.wdl

---

Unresolved question: import versioning

[rhpvorderman]

Great! This feature would be very nice. I think it is easier that imports are relative to the file and not $PWD but it would be better if this was explicit in the WDL file itself.

This would solve numerous issues with the versioning of imports, as you can put different versions in different directories/namespaces.

[aednichols]

@GregTD42 this may be of interest related to your recent Cromwell issue

[microbioticajon]

I would like to add my voice to this feature request too. I just ran into the the issue outlined in https://github.com/broadinstitute/cromwell/issues/6441.

Within a "package" relative imports ./ and ../ work nicely but when a wdl is imported within an import it is not intuitive for the user to work out what the relative path of the bundled dependency will be.