Conversation
- Update scaffold code and solutions to use topic channels (Channel.topic("versions")) instead of old softwareVersionsToYAML pattern
- Remove repo type prompt from module install docs (now set in .nf-core.yml by default)
- Fix stray backtick in section 1.5 import statement
- Bump nf-core version references from 3.4.1 to 3.5.2 across docs and devcontainer
- Fix hl_lines in section 1.3 scaffold block after topic channels code addition
- Add #!groovy syntax highlighting to closure inline code in 03_use_module.md
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add missing space after `{` in `.map{ meta, file -> file }` for
consistency with other inline closures in the same file.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Remove LLM-style patterns (Let's, feel free, Don't worry, exclamations) and replace with direct, professional phrasing throughout all lesson files. Also fix one incorrect hl_lines value in 02_rewrite_hello.md. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Reverts commit b286635 which applied overly strict CLAUDE.md writing style rules (removing "Let's", exclamations, etc.) to hello_nf-core lessons. Per reviewer feedback, these style guidelines are suggestions not mandates, and the original tone is preferred. Retains the functional fix: hl_lines="4" → hl_lines="2" in 02_rewrite_hello.md, which corrected an incorrectly highlighted line. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Rewrite section 1.6 in 04_make_module.md: concept-first explanation of topic channels, hands-on step adding topic:versions output to COWPY, run-and-verify step, backwards compat note - Add note at section 1.5.2 tree output pointing to section 1.6 - Update core-hello-part4 and core-hello-part5 cowpy/main.nf to use topic:versions syntax, remove legacy versions.yml approach - Update cat/cat nf-core module to latest version in all three solution directories (part3, part4, part5) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Docs fixes: - 02_rewrite_hello: fix config→conf typo in directory path - 03_use_module: add missing word "contain" in metamap description - 03_use_module: fix inconsistent comment between sections 3.3 and 3.4 - 04_make_module: remove incorrect shebang from module file code blocks - 04_make_module: fix stray \*\* in ext.prefix description - 04_make_module: fix versions YAML to show stripped process names Solution updates (rebuilt from proper nf-core 3.5.2 scaffold): - core-hello-part2 through part5: rebuilt and verified end-to-end - composable-hello: comment out params.greeting to match docs - original-hello: add main.nf entrypoint for composable workflow Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
original-hello/ is the starting point for learners - it should not contain Part 2 tutorial modifications (named workflow, main.nf). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Reorganize section 3 into: parameters, input validation, configuration. Replace general Nextflow content (already in Hello Config) with cross-references. Add concrete validation examples (unrecognized param, type mismatch, malformed samplesheet). Add GitHub browsing tip for pipeline source code. Include excalidraw diagrams for params vs config and config file structure. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
✅ Deploy Preview for nextflow-training ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Nextflow linting complete! ✅ 171 files had no errors View formatting changes
|
vdauwera
left a comment
There was a problem hiding this comment.
I like this reorg a lot! The additions on params and configs are really valuable. Left a few comments on small tweaks that I think would improve fit for the intended audience and tighten up a few things.
I do think we should still keep some of the material explaining code structure of the demo pipeline, but under a folded/optional section, for people who want to know but aren't going to do the hello rewrite etc.
I can make the changes I suggested if needed.
| </figure> | ||
|
|
||
| Let's have a look at how the pipeline code is organized in the `nf-core/demo` repository, using the `pipelines` symlink we created earlier. | ||
| ### 3.1. Get help |
There was a problem hiding this comment.
Feels like this is not really about getting help, it's getting usage info, so the title should be clearer about that.
| ### 3.1. Get help | ||
|
|
||
| You can either use `tree` or use the file explorer to find and open the `nf-core/demo` directory. | ||
| nf-core pipelines use the [nf-schema plugin](https://nextflow-io.github.io/nf-schema/latest/) to generate structured, grouped `--help` output automatically from the schema file. |
There was a problem hiding this comment.
Would flip this, explaining first what you can get (which is what a run-only person wants to know) then adding a note saying it works thanks to the nf-schema plugin, which plain Nextflow pipelines don't do by default (combine with later note about that)
| The standard nf-core pipeline code organization follows a modular structure that is designed to maximize code reuse, as introduced in [Hello Modules](../hello_nextflow/04_hello_modules.md), Part 4 of the [Hello Nextflow](../hello_nextflow/index.md) course, although in true nf-core fashion, this is implemented with a bit of additional complexity. | ||
| Specifically, nf-core pipelines make abundant use of subworkflows, i.e. workflow scripts that are imported by a parent workflow. | ||
| nf-core discourages setting parameters inside config files using `params { }` blocks. | ||
| Parameters defined in a custom config file passed with `-c` may not override defaults already set in the pipeline's own `nextflow.config`, depending on Nextflow's configuration precedence rules. |
There was a problem hiding this comment.
This feels like it would be confusing to someone not already aware of some advanced config stuff
| Using `--param_name` on the command line or `-params-file` is more reliable, as these always take precedence. | ||
|
|
||
| That may sound a bit abstract, so let's take a look how this is used in practice in the `nf-core/demo` pipeline. | ||
| !!! warning |
There was a problem hiding this comment.
not sure this should be a warning
| !!! warning | ||
|
|
||
| !!! note | ||
| As a rule of thumb: if it appears in the `--help` output, set it via the command line or a params file. Everything else belongs in a config file. |
There was a problem hiding this comment.
who is this rule of thumb for? runners or developers?
| ### 3.3. Input validation | ||
|
|
||
| #### 3.1.1. General overview | ||
| nf-core pipelines use the [nf-schema plugin](https://nextflow-io.github.io/nf-schema/latest/) to validate inputs at startup, before any processes run. |
There was a problem hiding this comment.
Again, flip this kind of statement to say what happens (inputs get validate), then how (using nf-schema) if needed
Moves exploration of pipeline code to Part 2: BUilding of an nf-core pipeline
Adds additional content to Part 1 to do more with validating parameters, samplesheets, and customizing configs and learning where nf-core keeps their configs
Ignore the excalidraw drawing, need some redoing