-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support Struct #9
Comments
We would like to use miniwdl for checking our pipelines at the Broad Institute, but the lack of struct support is preventing us from using it on most of our workflows. |
Hi, cool, I was wondering are any of these workflows open-sourced at this point? In the integration tests we embed numerous public repositories of workflows to ensure they're always parsed successfully. It will be great to add more exercising these novel areas of the spec. |
At this current point in time, no. The workflows we're running miniwdl on are all private. We are planning to get a public version out to you soon to use for testing. |
@infispiel it might transpire pretty soon that miniwdl supports structs and the soon-to-be struct literal syntax without supporting the JSON-like Basically since (purely due to timing) we've never supported |
@infispiel ping...the struct literal syntax continues to flux a little bit, so I'd really value your guidance on how to stage this. I recently completed most of the internal plumbing work for structs but obviously the literals are a key bit to make it usable. |
The usages we have look like this. Declarations:
Creation:
Which is what the current cromwell We can only use the syntax that cromwell currently supports, so supporting the next, as-yet-unimplemented, struct literal syntax in miniwdl wouldn't work for us. |
Regarding WDL 1 syntax vs the (newer) draft syntax, I think you'd want to support both. Even after the draft spec is approved and WDL 2 is out, there will still be existing WDL 1 workflows which miniwdl would want to support, since WDL 1 will continue to be supported by WDL runtimes. |
I didn't realize this before, but there are public versions of our WDL in github that can be used for testing miniwdl. The repo is https://github.com/gatk-workflows and an example of a workflow with structs is https://github.com/gatk-workflows/five-dollar-genome-analysis-pipeline |
@pshapiro4broad great stuff, thanks! It appears that in this particular version, the structs are all expected as JSON inputs, and there are no literal constructions in the WDL. Just an observation, it's coming along in any case. |
@pshapiro4broad also, a typo in one of the task WDLs makes the whole thing un-loadable :( filed this issue gatk-workflows/five-dollar-genome-analysis-pipeline#17 ...if you know the maintainer of that repo appreciate if you can bring it to their attention, thanks! |
Thanks for the bug report, looks like they're already on it. |
@pshapiro4broad @infispiel miniwdl v0.1.5 possibly might support structs to the extent you need as discussed above (including the |
Thanks for the discussion today! We currently pass an opaque Since there're no plans for EDIT: as a workaround, if I define |
Remaining burndown for full support in
miniwdl check
:object
literal syntaxhttps://github.com/openwdl/wdl/blob/master/versions/1.0/SPEC.md#struct-definition
openwdl/wdl#280
ident
ortype ident
, and the elements have no separator...........[]
make sense will get pushed here as wellName<doc-crc32c>
s
, we can references
itself or a members.m
ors.m.n
Person(name="Calvin", age=6).age
Expr.Ident
.left
/.right
access into this?Pair[Person,Person] p2
...p2.left.age
Array[Person] ar
...ar[42].age
name1.name2.name3
should be parsed differently depending on the type environment.name1
could refer to a value and.name2.name3
struct member accesses within. Orname1.name2
could be the namespaced value, andname3
a struct member.The text was updated successfully, but these errors were encountered: