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

Create new structure for the user guide #222

Closed
14 tasks
kinow opened this issue Jun 30, 2022 · 17 comments · Fixed by #226
Closed
14 tasks

Create new structure for the user guide #222

kinow opened this issue Jun 30, 2022 · 17 comments · Fixed by #226
Assignees

Comments

@kinow
Copy link
Member

kinow commented Jun 30, 2022

Part of common-workflow-language/common-workflow-language#219 , for post common-workflow-language/common-workflow-language#220

Supersedes common-workflow-language/common-workflow-language#5 (I've gone through its items and added them here).

Our user guide currently follows a Software Carpentry model, that is not ideal for a wider audience. This issue contains an initial brain dump for a new structure, but it will be refined after feedback in meetings and here on GitHub 👍

Table of Contents

  1. Quick start

  1. Prerequisites

  1. Basic Concepts
  • What is CWL, what is an implementation (show or point to a list of implementations), workflow, tool, steps

  1. Core Concepts
    4.1. CommandLineTool

  1. How-Tos

  1. Tutorials

  1. FAQ

  1. Extras

Notes, and remember-to's

Questions

Extras

Feel free to send any suggestions, critics, ideas, etc., update this issue, or link pull requests and issues to this one or to the parent placeholder (#219).

-Bruno

@kinow kinow self-assigned this Jun 30, 2022
@kinow
Copy link
Member Author

kinow commented Jul 2, 2022

Some useful links (references)

Guides and Reference material

Technical Writing

@mr-c
Copy link
Member

mr-c commented Jul 2, 2022

Questions

* Should we document cwltool specific behavior too? common-workflow-language/common-workflow-language#49 

In general, no. That particular feature is now part of the CWL standards without a prefix. It should be documented with a "v1.1+" badge.

https://www.commonwl.org/v1.1/CommandLineTool.html#InplaceUpdateRequirement

By now, everyone supports CWL v1.2 , so the user guide should use that version and not spend much time, if any, about differences from the previous versions.

@swzCuroverse
Copy link
Contributor

swzCuroverse commented Jul 2, 2022

Adding this in case you don't have it (II might have missed it)- we should explain what an implementation is - and explain the difference between cwl-tool and other implementations so it is clear there are other implementations if you want to run at scale/have an platform/want commercial support/want to integrate with another tool (i.e. Galaxy)

I have another list Peter/I drew up awhile ago so I will find it and cut and paste here in a bit.

@swzCuroverse
Copy link
Contributor

Additional thoughts - I think at the beginning you should explain the general difference between a tool, workflow and expression tool. I think that is what you have in the Basics but just in case I am putting this here:

Other topics that might be of interest include:

  • FAIR best practices with CWL
  • Testing and Debugging CWL Workflows
  • Integration with existing Workflow and Tool Repositories
  • Guides on Running CWL in Production on Specific Platforms
    • These could just be links to existing documentation to the fully supported platforms listed on the website
  • We were hoping to come up with templates or a library of common used actions but some of these could be explained in the user guide
    ** https://github.com/common-workflow-library/cwl-patterns/blob/main/README.md

You can use Peter's tutorial here for some examples: https://github.com/arvados/rnaseq-cwl-training
Also useful for setting up vscode: https://github.com/arvados/arvados-vscode-cwl-training

@kinow
Copy link
Member Author

kinow commented Jul 6, 2022

Hi @swzCuroverse !

I think at the beginning you should explain the general difference between a tool, workflow and expression tool. I think that is what you have in the Basics but just in case I am putting this here

Agreed 👍

Other topics that might be of interest include:

Excellent list of resources! We can include most of these items under Tutorials & How-Tos, and the good practices definitely needs to be put somewhere well visible to users. In the last Biocommons workflows meeting (Australia) there was a poll about workflows after the Janis presentation, where many participants pointed they'd like to know where to find best practices about workflow tools (not only CWL).

And my bad for not including FAIR! It completely slipped my mind, great point.

Thank you!

@skanwal
Copy link

skanwal commented Jul 6, 2022

Thanks @kinow - this is a great and comprehensive list of contents, resources and to-do's.

My two cents are:

@kinow
Copy link
Member Author

kinow commented Jul 6, 2022

Hi @skanwal

My two cents are:

+1 to all your points! I also struggled with arguments vs. inputs, and even now sometimes I use an input in some cases where an argument would be simpler 😅

Keep sending the suggestions if you have any more. I received some feedback from @tetron and @swzCuroverse this week, and I'll add it to the top comment later (updating the PR for the theme/sphinx at the moment).

Thank you!!!
Bruno

@kinow kinow pinned this issue Jul 7, 2022
@kinow
Copy link
Member Author

kinow commented Jul 7, 2022

I have pinned this issue to attract more attention to users coming to report issues.

Also added links to each section of the current User Guide in bold. You can search by "episode" if you prefer too. I called every page an episode, even though not all were episodes (e.g. Extras > YAML is "episode YAML") so that searching for it is easier here 👍 cc @tetron

@kinow
Copy link
Member Author

kinow commented Jul 11, 2022

Added the Wiki about using TypeScript with CWL that @alexiswl presented yesterday in the APAC-EMEA meeting. I added it under Advanced Topics as suggested by @skanwal , but maybe it should be duplicated or mentioned in Recommended Practices too (I would recommend it for users maintaining long or complicated JS expressions).

@skanwal
Copy link

skanwal commented Jul 11, 2022

+1 for mentioning under both sections @kinow

@mr-c

This comment was marked as duplicate.

1 similar comment
@mr-c
Copy link
Member

mr-c commented Jul 12, 2022

Added the Wiki about using TypeScript with CWL that @alexiswl presented yesterday in the APAC-EMEA meeting. I added it under Advanced Topics as suggested by @skanwal , but maybe it should be duplicated or mentioned in Recommended Practices too (I would recommend it for users maintaining long or complicated JS expressions).

This needs review before becoming a "recommended practice". Transpiling is cool, but how might that affect re-use?

@kinow
Copy link
Member Author

kinow commented Jul 12, 2022

Added the Wiki about using TypeScript with CWL that @alexiswl presented yesterday in the APAC-EMEA meeting. I added it under Advanced Topics as suggested by @skanwal , but maybe it should be duplicated or mentioned in Recommended Practices too (I would recommend it for users maintaining long or complicated JS expressions).

This needs review before becoming a "recommended practice". Transpiling is cool, but how might that affect re-use?

Yup, maybe Advanced Topics would be a better home for this then. I mentioned to @alexiswl , that would be nice to have some of pros & cons (the pros being pretty much implicit), e.g.:

  • It hinders portability within a team of CWL workflow developers, if any one of them is not familiar with TypeScript
  • It also hinders portability between workflow manager tools, as translating CWL JS expressions into other standards/languages like WDL or Nextflow's DSL is complicated; adding an extra level makes it harder
  • It can also create issues if there are issues with tsc or jest versions, or if there are extra tools involved (Babel, Vite, esbuild, etc)

@alexiswl
Copy link
Contributor

the pros being pretty much implicit

I’m not sure all of the pros are implicit, they certainly weren’t for me until I started playing around. And this I assume is the case for many devs unfamiliar with TypeScript.

It hinders portability within a team of CWL workflow developers, if any one of them is not familiar with TypeScript

Yes and no to this one. I think TypeScript is much easier to read than ES5 JavaScript, but also very easy to pick up if a user knows JS. So, if a user is not familiar with TypeScript, I doubt that they’re particularly familiar with JavaScript. An alternative argument is that the TypeScript methods might mean that users use the JavaScript expressions of CWL more extensively, which pushes out developers unfamiliar with the TypeScript syntax.

It also hinders portability between workflow manager tools, as translating CWL JS expressions into other standards/languages like WDL or Nextflow's DSL is complicated; adding an extra level makes it harder

Yes and no to this one too. I think TypeScript would be very consistent on its methods of transpiling to ES5 code so that could be a benefit. I’m not familiar with the processes on how this would be converted to a language like WDL. I think this would be an issue with JavaScript expressions in general and should be noted in the user guide if a developer wants to make their workflows language agnostic.

It can also create issues if there are issues with tsc or jest versions, or if there are extra tools involved (Babel, Vite, esbuild, etc)

This is where a package-lock.json file would be useful and should make the transpilation and testing reproducible.

@kinow
Copy link
Member Author

kinow commented Jul 20, 2022

Hi @AlexisW, good pointsl ! I've created the issue common-workflow-language/common-workflow-language#227 to move the discussion over there 👍

@swzCuroverse
Copy link
Contributor

@kinow Can you help me figure out which parts are left "to-do"?

@kinow
Copy link
Member Author

kinow commented Sep 24, 2022

@kinow Can you help me figure out which parts are left "to-do"?

Sure. I think the unchecked boxes have not been addressed here as we decided to prioritize the new structure. I left notes to myself and to future developers in the source code. So the Markdown files must contain comments (start with %), some with TODO markers that contain links to issues/pull requests/discussions. I can try to compile or review a list later (ran out of time to have fun working on CWL this weekend unfortunately 😥 👋 )

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

Successfully merging a pull request may close this issue.

5 participants