removed the option of initializing the pipeline with samplesheet and network parameter

.github/PULL_REQUEST_TEMPLATE.md

@@ -8,14 +8,14 @@ These are the most common things requested on pull requests (PRs).
 
 Remember that PRs should be made against the dev branch, unless you're preparing a pipeline release.
 
-Learn more about contributing: [CONTRIBUTING.md](https://github.com/nf-core/diseasemodulediscovery/tree/main/docs/CONTRIBUTING.md)
+Learn more about contributing: [CONTRIBUTING.md](https://github.com/nf-core/diseasemodulediscovery/tree/master/.github/CONTRIBUTING.md)
 -->
 
 ## PR checklist
 
 - [ ] This comment contains a description of changes (with reason).
 - [ ] If you've fixed a bug or added code that should be tested, add tests!
-- [ ] If you've added a new tool - have you followed the pipeline conventions in the [contribution docs](https://github.com/nf-core/diseasemodulediscovery/tree/main/docs/CONTRIBUTING.md)
+- [ ] If you've added a new tool - have you followed the pipeline conventions in the [contribution docs](https://github.com/nf-core/diseasemodulediscovery/tree/master/.github/CONTRIBUTING.md)
 - [ ] If necessary, also make a PR on the nf-core/diseasemodulediscovery _branch_ on the [nf-core/test-datasets](https://github.com/nf-core/test-datasets) repository.
 - [ ] Make sure your code lints (`nf-core pipelines lint`).
 - [ ] Ensure the test suite passes (`nextflow run . -profile test,docker --outdir <OUTDIR>`).

.github/workflows/branch.yml

@@ -21,7 +21,7 @@ jobs:
       # NOTE - this doesn't currently work if the PR is coming from a fork, due to limitations in GitHub actions secrets
       - name: Post PR comment
         if: failure()
-        uses: mshick/add-pr-comment@8e4927817251f1ff60c001f04568532b38e0b4a0 # v3
+        uses: mshick/add-pr-comment@b8f338c590a895d50bcbfa6c5859251edc8952fc # v2
         with:
           message: |
             ## This PR is against the `${{github.event.pull_request.base.ref}}` branch :x:

.github/workflows/linting.yml

@@ -11,50 +11,54 @@ jobs:
   pre-commit:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
+      - uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5
 
-      - name: Install Nextflow
-        uses: nf-core/setup-nextflow@b4ec1bc7c16a94435159de94a05253542fddf6ef # v3
+      - name: Set up Python 3.14
+        uses: actions/setup-python@e797f83bcb11b83ae66e0230d6156d7c80228e7c # v6
+        with:
+          python-version: "3.14"
 
-      - name: Run prek
-        uses: j178/prek-action@6ad80277337ad479fe43bd70701c3f7f8aa74db3 # v2
+      - name: Install pre-commit
+        run: pip install pre-commit
+
+      - name: Run pre-commit
+        run: pre-commit run --all-files
 
   nf-core:
     runs-on: ubuntu-latest
     steps:
       - name: Check out pipeline code
-        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
+        uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5
 
       - name: Install Nextflow
-        uses: nf-core/setup-nextflow@b4ec1bc7c16a94435159de94a05253542fddf6ef # v3
+        uses: nf-core/setup-nextflow@v2
 
-      - uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6
+      - uses: actions/setup-python@e797f83bcb11b83ae66e0230d6156d7c80228e7c # v6
         with:
           python-version: "3.14"
           architecture: "x64"
 
-      - name: Setup uv
-        uses: astral-sh/setup-uv@08807647e7069bb48b6ef5acd8ec9567f424441b # v8.1.0
-
       - name: read .nf-core.yml
         uses: pietrobolcato/action-read-yaml@9f13718d61111b69f30ab4ac683e67a56d254e1d # 1.1.0
         id: read_yml
         with:
           config: ${{ github.workspace }}/.nf-core.yml
 
       - name: Install dependencies
-        run: uv tool install nf-core==${{ steps.read_yml.outputs['nf_core_version'] }}
+        run: |
+          python -m pip install --upgrade pip
+          pip install nf-core==${{ steps.read_yml.outputs['nf_core_version'] }}
 
       - name: Run nf-core pipelines lint
-        if: ${{ github.base_ref != 'master' || github.base_ref != 'main' }}
+        if: ${{ github.base_ref != 'master' }}
         env:
           GITHUB_COMMENTS_URL: ${{ github.event.pull_request.comments_url }}
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           GITHUB_PR_COMMIT: ${{ github.event.pull_request.head.sha }}
         run: nf-core -l lint_log.txt pipelines lint --dir ${GITHUB_WORKSPACE} --markdown lint_results.md
 
       - name: Run nf-core pipelines lint --release
-        if: ${{ github.base_ref == 'master' || github.base_ref == 'main' }}
+        if: ${{ github.base_ref == 'master' }}
         env:
           GITHUB_COMMENTS_URL: ${{ github.event.pull_request.comments_url }}
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
@@ -67,7 +71,7 @@ jobs:
 
       - name: Upload linting log file artifact
         if: ${{ always() }}
-        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7
+        uses: actions/upload-artifact@330a01c490aca151604b8cf639adc76d48f6c5d4 # v5
         with:
           name: linting-logs
           path: |

.github/workflows/linting_comment.yml

@@ -11,7 +11,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Download lint results
-        uses: dawidd6/action-download-artifact@b6e2e70617bc3265edd6dab6c906732b2f1ae151 # v21
+        uses: dawidd6/action-download-artifact@ac66b43f0e6a346234dd65d4d0c8fbb31cb316e5 # v11
         with:
           workflow: linting.yml
           workflow_conclusion: completed
@@ -21,7 +21,7 @@ jobs:
         run: echo "pr_number=$(cat linting-logs/PR_number.txt)" >> $GITHUB_OUTPUT
 
       - name: Post PR comment
-        uses: marocchino/sticky-pull-request-comment@70d2764d1a7d5d9560b100cbea0077fc8f633987 # v3
+        uses: marocchino/sticky-pull-request-comment@773744901bac0e8cbb5a0dc842800d45e9b2b405 # v2
         with:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           number: ${{ steps.pr_number.outputs.pr_number }}

.prettierignore

@@ -1,4 +1,6 @@
 email_template.html
+adaptivecard.json
+slackreport.json
 .nextflow*
 work/
 data/

docs/CONTRIBUTING.md

@@ -1,185 +1,17 @@
----
-title: Contributing
-markdownPlugin: checklist
----
-
-# `nf-core/diseasemodulediscovery`: Contributing guidelines
-
-Hi there!
-Thanks for taking an interest in improving nf-core/diseasemodulediscovery.
-
-This page describes the recommended nf-core way to contribute to both nf-core/diseasemodulediscovery and nf-core pipelines in general, including:
-
-- [General contribution guidelines](#general-contribution-guidelines): common procedures or guides across all nf-core pipelines.
-- [Pipeline-specific contribution guidelines](#pipeline-specific-contribution-guidelines): procedures or guides specific to the development conventions of nf-core/diseasemodulediscovery.
-
-> [!NOTE]
-> If you need help using or modifying nf-core/diseasemodulediscovery, ask on the nf-core Slack [#diseasemodulediscovery](https://nfcore.slack.com/channels/diseasemodulediscovery) channel ([join our Slack here](https://nf-co.re/join/slack)).
-
-## General contribution guidelines
-
-### Contribution quick start
-
-To contribute code to any nf-core pipeline:
-
-- [ ] Ensure you have Nextflow, nf-core tools, and nf-test installed. See the [nf-core/tools repository](https://github.com/nf-core/tools) for instructions.
-- [ ] Check whether a GitHub [issue](https://github.com/nf-core/diseasemodulediscovery/issues) about your idea already exists. If an issue does not exist, create one so that others are aware you are working on it.
-- [ ] [Fork](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) the [nf-core/diseasemodulediscovery repository](https://github.com/nf-core/diseasemodulediscovery) to your GitHub account.
-- [ ] Create a branch on your forked repository and make your changes following [pipeline conventions](#pipeline-contribution-conventions) (if applicable).
-- [ ] To fix major bugs, name your branch `patch` and follow the [patch release](#patch-release) process.
-- [ ] Update relevant documentation within the `docs/` folder, use nf-core/tools to update `nextflow_schema.json`, and update `CITATIONS.md`.
-- [ ] Run and/or update tests. See [Testing](#testing) for more information.
-- [ ] [Lint](#lint-tests) your code with nf-core/tools.
-- [ ] Submit a pull request (PR) against the `dev` branch and request a review.
-
-If you are not used to this workflow with Git, see the [GitHub documentation](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests) or [Git resources](https://try.github.io/) for more information.
-
-## Use of AI and LLMs
-
-The nf-core stance on the use of AI and LLMs is that humans are still ultimately responsible for their submitted code, regardless of the tools they use.
-
-If you’re using AI tools, try to stick by these guidelines:
-
-- Keep PRs as small and focussed as possible
-- Avoid any unnecessary changes, such as moving or refactoring code (unless that is the explicit intention of the PR)
-- Review all generated code yourself before opening a PR, and ensure that you understand it
-- Engage with the community review process and expect to make revisions
-
-For more detail, see the the [blog post](https://nf-co.re/blog/2026/statement-on-ai) for a statement from the nf-core/core team.
-
-### Getting help
-
-For further information and help, see the [nf-core/diseasemodulediscovery documentation](https://nf-co.re/diseasemodulediscovery/usage) or ask on the nf-core [#diseasemodulediscovery](https://nfcore.slack.com/channels/diseasemodulediscovery) Slack channel ([join our Slack here](https://nf-co.re/join/slack)).
-
-### GitHub Codespaces
-
-You can contribute to nf-core/diseasemodulediscovery without installing a local development environment on your machine by using [GitHub Codespaces](https://github.com/codespaces).
-
-[GitHub Codespaces](https://github.com/codespaces) is an online developer environment that runs in your browser, complete with VS Code and a terminal.
-Most nf-core repositories include a devcontainer configuration, which creates a GitHub Codespaces environment specifically for Nextflow development.
-The environment includes pre-installed nf-core tools, Nextflow, and a few other helpful utilities via a Docker container.
-
-To get started, open the repository in [Codespaces](https://github.com/nf-core/diseasemodulediscovery/codespaces).
-
-### Testing
-
-Once you have made your changes, run the pipeline with nf-test to test them locally.
-For additional information, use the `--verbose` flag to view the Nextflow console log output.
-
-```bash
-nf-test test --tag test --profile +docker --verbose
-```
-
-If you have added new functionality, ensure you update the test assertions in the `.nf.test` files in the `tests/` directory.
-Update the snapshots with the following command:
-
-```bash
-nf-test test --tag test --profile +docker --verbose --update-snapshots
-```
-
-When you create a pull request with changes, GitHub Actions will run automatic tests.
-Pull requests are typically reviewed when these tests are passing.
-
-Two types of tests are typically run:
-
-#### Lint tests
-
-nf-core has a [set of guidelines](https://nf-co.re/docs/specifications/overview) which all pipelines must follow.
-To enforce these, run linting with nf-core/tools:
-
-```bash
-nf-core pipelines lint <pipeline_directory>
-```
-
-If you encounter failures or warnings, follow the linked documentation printed to screen.
-For more information about linting tests, see [nf-core/tools API documentation](https://nf-co.re/docs/nf-core-tools/api_reference/latest/pipeline_lint_tests/actions_awsfulltest).
-
-#### Pipeline tests
-
-Each nf-core pipeline should be set up with a minimal set of test data.
-GitHub Actions runs the pipeline on this data to ensure it runs through and exits successfully.
-If there are any failures then the automated tests fail.
-These tests are run with the latest available version of Nextflow and the minimum required version specified in the pipeline code.
-
-### Patch release
-
-> [!WARNING]
-> Only in the unlikely event of a release that contains a critical bug.
-
-- [ ] Create a new branch `patch` on your fork based on `upstream/main` or `upstream/master`.
-- [ ] Fix the bug and use nf-core/tools to bump the version to the next semantic version, for example, `1.2.3` → `1.2.4`.
-- [ ] Open a Pull Request from `patch` directly to `main`/`master` with the changes.
-
-### Pipeline contribution conventions
-
-nf-core semi-standardises how you write code and other contributions to make the nf-core/diseasemodulediscovery code and processing logic more understandable for new contributors and to ensure quality.
-
-#### Add a new pipeline step
-
-To contribute a new step to the pipeline, follow the general nf-core coding procedure.
-Please also refer to the [pipeline-specific contribution guidelines](#pipeline-specific-contribution-guidelines):
-
-- [ ] Define the corresponding [input channel](#channel-naming-schemes) into your new process from the expected previous process channel.
-- [ ] Install a module with nf-core/tools, or write a local module (see [default processes resource requirements](#default-processes-resource-requirements)), and add it to the target `<workflow>.nf`.
-- [ ] Define the output channel if needed. Mix the version output channel into `ch_versions` and relevant files into `ch_multiqc`.
-- [ ] Add new or updated parameters to `nextflow.config` with a [default value](#default-parameter-values).
-- [ ] Add new or updated parameters and relevant help text to `nextflow_schema.json` with [nf-core/tools](#default-parameter-values).
-- [ ] Add validation for relevant parameters to the pipeline utilisation section of `utils_nfcore_\_pipeline/main.nf` subworkflow.
-- [ ] Perform local tests to validate that the new code works as expected.
-  - [ ] If applicable, add a new test in the `tests` directory.
-- [ ] Update `usage.md`, `output.md`, and `citation.md` as appropriate.
-- [ ] [Lint](lint) the code with nf-core/tools.
-- [ ] Update any diagrams or pipeline images as necessary.
-- [ ] Update MultiQC config `assets/multiqc_config.yml` so relevant suffixes, file name cleanup, and module plots are in the appropriate order.
-- [ ] If applicable, create a [MultiQC](https://seqera.io/multiqc/) module.
-- [ ] Add a description of the output files and, if relevant, images from the MultiQC report to `docs/output.md`.
-
-To update the minimum required Nextflow version, see the [Nextflow version bumping](#nextflow-version-bumping) section below. For more information about pipeline contributions, see [pipeline-specific contribution guidelines](#pipeline-specific-contribution-guidelines).
-
-#### Channel naming schemes
-
-Use the following naming schemes for channels to make the channel flow easier to understand:
-
-- Initial process channel: `ch_output_from_<process>`
-- Intermediate and terminal channels: `ch_<previousprocess>_for_<nextprocess>`
-
-#### Default parameter values
-
-Parameters should be initialised and defined with default values within the `params` scope in `nextflow.config`.
-They should also be documented in the pipeline JSON schema.
-
-To update `nextflow_schema.json`, run:
-
-```bash
-nf-core pipelines schema build
-```
-
-The schema builder interface that loads in your browser should automatically update the defaults in the parameter documentation.
-
-#### Default processes resource requirements
-
-If you write a local module, specify a default set of resource requirements for the process.
-
-Sensible defaults for process resource requirements (CPUs, memory, time) should be defined in `conf/base.config`.
-Specify these with generic `withLabel:` selectors, so they can be shared across multiple processes and steps of the pipeline.
-
-nf-core provides a set of standard labels that you should follow where possible, as seen in the [nf-core pipeline template](https://github.com/nf-core/tools/blob/main/nf_core/pipeline-template/conf/base.config).
-These labels define resource defaults for single-core processes, modules that require a GPU, and different levels of multi-core configurations with increasing memory requirements.
-
-Values assigned within these labels can be dynamically passed to a tool using the the `${task.cpus}` and `${task.memory}` Nextflow variables in the `script:` block of a module (see an example in the [modules repository](https://github.com/nf-core/modules/blob/bd1b6a40f55933d94b8c9ca94ec8c1ea0eaf4b82/modules/nf-core/samtools/bam2fq/main.nf#L30)).
-
-#### Nextflow version bumping
-
-If you use a new feature from core Nextflow, bump the minimum required Nextflow version in the pipeline with:
-
-```bash
-nf-core pipelines bump-version --nextflow . <min_nf_version>
-```
-
-#### Images and figures guidelines
-
-If you update images or graphics, follow the nf-core [style guidelines](https://nf-co.re/docs/community/brand/workflow-schematics).
-
-## Pipeline specific contribution guidelines
-
-<!-- TODO nf-core: Add any pipeline specific contribution guidelines here, such as coding styles, procedures, checklists etc. -->
+# Including a new active module detection tool
+
+1. Create a new branch for your tool.
+2. Add a function to the bin/graph_tool_parser.py script for preparing the tool-specific network input format. The script is built around the [graph-tool](https://graph-tool.skewed.de/) Python package. An example is the safe_diamond() function, which saves a simple edge list in CSV format. Add the function as an option in the save() function and a command line option for `--format` in parse_args(). The output file name has to include the option specified with `--format` since nextflow uses this pattern to check whether the output file was successfully generated. The script expects a .gt file as input. Run the pipeline with the "test" profile to generate a .gt example file in `<OUTDIR>/graphtoolparser`, which you can use to test the parsing function by executing the parsing script directly via the command line.
+3. Create a module for the tool. (Example with comments: `modules/local/diamond/main.nf` and `modules/local/domino/`)
+4. Create a subworkflow wrapping the tool together with the input parser. (Example with comments: `subworkflows/local/gt_diamond/main.nf` and `subworkflows/local/gt_domino/main.nf`)
+5. Include the subworkflow in the `workflows/modulediscovery.nf` file. Again, DIAMOnD and DOMINO are included as examples.
+6. Test checks locally:
+   1. Run tests via, e.g., `nextflow run main.nf -profile singularity,test --outdir results`.
+   2. Run `nf-core lint`.
+   3. Check your code style. This will automatically happen before you commit, if you use pre-commit, which can be set up with: `pre-commit install`. After each commit, it will automatically check your code style and fix it where possible. If changes were made, you have to commit again.
+7. Create a pull request against the dev branch.
+
+Further information
+
+- [FAQ sheet](https://docs.google.com/document/d/1WgBIFrrcxFKN0I-zJbuS7PUCmyCLPTWx6xAHg1zi4FA/edit?usp=sharing)
+- [Workflow schema](https://docs.google.com/drawings/d/1X7U79dAZaeRdGdIsXoEKw74MNqjxCHq3RuNASBYCiB4/edit?usp=sharing)