-
Notifications
You must be signed in to change notification settings - Fork 259
[EXAMPLE] hello-nextflow: new Nextflow syntax (full) #742
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
Conversation
Mostly written by Claude, with some guiding and edits from @ewels. Solutions scripts tested, but material not read and checked in detail yet.
✅ Deploy Preview for nextflow-training ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Nextflow linting complete! ❌ 4 files had 23 errors 💡 Tip: Click filename locations to go directly to that code. View all 23 issues
|
| Set the following environment variable before running any workflows: | ||
|
|
||
| ```bash | ||
| export NXF_SYNTAX_PARSER=v2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we going to set this by default in the training environment? If so, can we make this a much shorter note to tell people running in their own environment to check requirements for local installation, and have the details live there? I really don't want to add a half page of warnings about previews and syntax requirements in a beginner training intro.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can do, but that'll tell Nextflow to use the new syntax parser for all the training courses. Which we don't want yet, until they're all updated.
This is where timelines matter. This will become the default in 2026, so won't be needed from that point onwards. So if we're fast at updating all the courses, then yes - let's stick it into the dev environment. If not, then I think we need to tell people to do it themselves.
Probably the most user-friendly way to do this is to have an interactive script that runs on codespaces init that prompts the user to ask which course they're doing, then sets some env variables accordingly.
Or, *controvercy alert*, we split up the courses into separate repos and/or containers and have one per course.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hahaha I hate both of those options. I don't want to have major differences in requirements for different courses except for specific super advanced topics, and they all have to work within a single environment.
So we just update syntax for everything in one go. It's the most sane option for end-users.
pditommaso
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not think we should include preview features in the training material
Completely agree. We've discussed this over slack and are making a plan to do the updates for released features now (use strict syntax across all courses) and another batch mid-year once the preview features are released. |
Yeah apologies - I opened the PR in tandem with an ongoing Slack thread so the context there was clear, but not when seeing the PR stand alone. I've updated the PR description and status to make this clear. |
|
Awesome, thanks 🙏 |
| output: | ||
| path 'output.txt' | ||
| file 'output.txt' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor point since typed processes shouldn't be used here until they are stable, but the "canonical" syntax here should use parentheses because it is just a function call returning a value, not a type qualifier like in the old process syntax
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Worth updating the docs in that case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the docs are pretty clear
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, too many types!
| nextflow.preview.types = true | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not needed here. Did the language server add this? It should only add this flag if there were processes that were auto-converted
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No this was me / claude being over-zealous in adding it. I didn't do any language server auto-correction here.
|
Ok I pulled out the parts of this PR that are for inputs + outputs + strict syntax and put them into a separate PR: #743 Can leave this one here for future reference if we want, or just close it out (can always refer to it in closed state). |
Let's close it out to avoid confusion |
I didn't really mean to do this, I was just sort of curious and prodding around with @claude, then one thing led to another, and here we are.. 🤷🏻
This PR includes *all* upcoming syntax changes. Primarily:
It is meant as a demonstrator of what kind of changes will be needed for the training material - I'm not expecting that we merge as-is. It's possible that we can slice off some of this work and repackage in another PR to kickstart the update process.