Skip to content
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

simple command line tool for local execution #203

Open
KerstenBreuer opened this issue Jul 21, 2018 · 1 comment
Open

simple command line tool for local execution #203

KerstenBreuer opened this issue Jul 21, 2018 · 1 comment

Comments

@KerstenBreuer
Copy link

Hey there,
I understand the benefit of running cwlviewer on a webserver so that anybody can use the tool without installation. However, I think for most people it would be much more convenient to provide a simple command line tool that can be used to produce such overview image locally. I would appreciate something like this:
cwlviewer -wf my_workflow.cwl -img workflow_overview.png

I think that workflow visualization should be an integral part of every workflow execution. With such a command line utility, one could automatically execute cwlviewer for every workflow run and store the generated overview image as part of the experiment's documentation together with the results.

In the current form, cwlviewer is only of limited use for me since my workflows are often created on the fly and I don't want to upload them to a public git repository every time.

CWL viewer is a great tool, I would really appreciate your help on this.

@stain
Copy link
Member

stain commented Aug 20, 2018

I think this would be a nice Google Summer of Code project or similar, however the current architecture is a bit tied into having a file store with git checkouts, a SPARQL store and a mongo db to wire it together. Obviously you would not want to spin up all that just to visualize on the command line.

In theory something like cwltool --print-rdf | cwlviewer -dot | dot -Tsvg > workflow.svg would work (or Java code to execute that pipeline), if you base the code of the RDFDotWriter

but you would then need to rewrite RDFService.runQuery to not connect to a HTTP Sparql Service, but to query with ARQ directly on an internal Jena model loaded from that --print-rdf.

An alternative to the SPARQL/RDF queries is to use the simpler parseWorkflowNative method that uses it's own YAML parser to generate a more naive dot rendering (this is what is shown in the background during loading). This might struggle with some more exotic workflow files as it does not use cwltool, but it probably could do the job and might be a bit faster.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants