`nextflow inspect` no longer respects container overrides from config for `withName`

[awgymer]

Bug report

In previous versions of nextflow inspect container overrides set using any withName selectors were respected and reported correctly. Since (at least) 25.04 this is broken and overrides only work from withName that uses only the process name (e.g. not alias, fully qualified name, partial qualified process name etc).

Expected behavior and actual behavior

For the following workflow main.nf please see the working/non-working examples.

process A_A { 

    script:
    """
    echo test
    """
}

process A_B { 

    script:
    """
    echo test
    """
}

workflow PARENT {
    A_A()
    A_B()
}

workflow {
    PARENT()
}

Working in both

Process name only

nextflow.config

process {

    withName: A_A {
        container = "docker.io/google/deepvariant:1.8.0"
    }

}

24.10.5

{
    "processes": [
        {
            "name": "PARENT:A_A",
            "container": "docker.io/google/deepvariant:1.8.0"
        }
    ]
}

25.04.3

{
    "processes": [
        {
            "name": "A_A",
            "container": "docker.io/google/deepvariant:1.8.0"
        }
    ]
}

Quoted process name only

nextflow.config

process {

    withName: "A_A" {
        container = "docker.io/google/deepvariant:1.8.0"
    }

}

24.10.5

{
    "processes": [
        {
            "name": "PARENT:A_A",
            "container": "docker.io/google/deepvariant:1.8.0"
        }
    ]
}

25.04.3

{
    "processes": [
        {
            "name": "A_A",
            "container": "docker.io/google/deepvariant:1.8.0"
        }
    ]
}

Partial process name

nextflow.config

process {

    withName: "A_.*" {
        container = "docker.io/google/deepvariant:1.8.0"
    }

}

24.10.5

nextflow inspect main.nf
{
    "processes": [
        {
            "name": "PARENT:A_B",
            "container": "docker.io/google/deepvariant:1.8.0"
        },
        {
            "name": "PARENT:A_A",
            "container": "docker.io/google/deepvariant:1.8.0"
        }
    ]
}

25.04.3

{
    "processes": [
        {
            "name": "A_B",
            "container": "docker.io/google/deepvariant:1.8.0"
        },
        {
            "name": "A_A",
            "container": "docker.io/google/deepvariant:1.8.0"
        }
    ]
}

Working only in 24.10.5

Fully qualified process name

nextflow.config

process {

    withName: "PARENT:A_A" {
        container = "docker.io/google/deepvariant:1.8.0"
    }

}

24.10.5

{
    "processes": [
        {
            "name": "PARENT:A_A",
            "container": "docker.io/google/deepvariant:1.8.0"
        }
    ]
}

25.04.3

{
    "processes": [
    ]
}

Partial qualified process name

nextflow.config

process {

    withName: ".*RENT:A_A" {
        container = "docker.io/google/deepvariant:1.8.0"
    }

}

24.10.5

{
    "processes": [
        {
            "name": "PARENT:A_A",
            "container": "docker.io/google/deepvariant:1.8.0"
        }
    ]
}

25.04.3

{
    "processes": [
    ]
}

ALIASING

For the following tests module definitions were moved to module.nf and top-level main.nf is now

include { A_A; A_A as A_B } from './module.nf'

workflow PARENT {
    A_A()
    A_B()
}

workflow {
    PARENT()
}

Alias by base name

nextflow.config

process {

    withName: A_A {
        container = "docker.io/google/deepvariant:1.8.0"
    }

}

24.10.5

{
    "processes": [
        {
            "name": "PARENT:A_B",
            "container": "docker.io/google/deepvariant:1.8.0"
        },
        {
            "name": "PARENT:A_A",
            "container": "docker.io/google/deepvariant:1.8.0"
        }
    ]
}

25.04.3

{
    "processes": [
        {
            "name": "A_A",
            "container": "docker.io/google/deepvariant:1.8.0"
        }
    ]
}

Alias by alias

nextflow.config

process {

    withName: "A_B" {
        container = "docker.io/google/deepvariant:1.8.0"
    }

}

24.10.5

{
    "processes": [
        {
            "name": "PARENT:A_B",
            "container": "docker.io/google/deepvariant:1.8.0"
        }
    ]
}

25.04.3

{
    "processes": [
        
    ]
}

Alias by alias and base name

nextflow.config

process {

    withName: "A_B" {
        container = "docker.io/google/deepvariant:1.9.0"
    }


    withName: "A_A" {
        container = "docker.io/google/deepvariant:1.8.0"
    }

}

24.10.5

{
    "processes": [
        {
            "name": "PARENT:A_B",
            "container": "docker.io/google/deepvariant:1.9.0"
        },
        {
            "name": "PARENT:A_A",
            "container": "docker.io/google/deepvariant:1.8.0"
        }
    ]
}

25.04.3

{
    "processes": [
        {
            "name": "A_A",
            "container": "docker.io/google/deepvariant:1.8.0"
        }
    ]
}

I haven't tested overrides by e.g. withLabel but as you can see it appears that since at least 25.04.3 the nextflow inspect command reports only "base modules" and not the fully qualified names/paths as in 24.10.5 and this appears to affect the correctness of the reporting.

Environment

• Nextflow version: 25.04.3
• Java version: openjdk version "21.0.7" 2025-04-15 LTS
• Operating system: macOS

[bentsherman]

This is the expected behavior in 25.04. nextflow inspect now extracts the container settings by looking directly at the process definitions instead of executing the workflow, which allows it to be faster and capture every process that could be used

The limitation is that nextflow inspect no longer knows anything about fully-qualified names or include aliases. We concluded this limitation would be acceptable, because in principle you should never need to specify a different container for different instances of a process in the execution stack.

This means that if you specify containers in the config, you need to select the base process name instead of using aliases or workflow prefixes.

[awgymer]

Hmm whilst I appreciate the need to simplify and also the desire to support inspect without the need to execute the workflow this does push you towards some unnecessary config duplication imo.

There are plenty of good reasons to need to use withName blocks with fully or part-qualified names and this means you now need to maintain separate withName blocks to override the containers for each process. It also means that you can't just set a container for an entire subworkflow.

Finally inspect presented a good method previously to get the fully qualified names of your processes in a pipeline and it's a bit of a shame to lose that.

I wonder if it's possible to support running both with and without execution or if the code from the older implementation is just too much of a maintenance burden to be kept around?

[bentsherman]

The real purpose of the change was to actually be able to extract all processes in a pipeline, without specifying any parameters, because before you would only get the processes executed by a particular "route" based on the parameters you gave.

It should be possible to have the best of both worlds (fully-qualified process names and completeness) using the new syntax parser, and in the future I will probably implement this and maybe have a "concise" vs "full" mode. It's just not a high priority. The overwhelming motivation for nextflow inspect was to get the full list of containers, and the current implementation satisfies that.

[awgymer]

get the full list of containers, and the current implementation satisfies that

With the limitation that it misses containers set using qualified or aliased process names. I think that at least needs to be documented because I was banging my head against a wall with inspect yesterday thinking I had my selectors written incorrectly.

Where and how it gets documented (inspect command / container directive / both etc) probably depends on whether "containers should be the same for all instances of a process" is a recommendation or if it is going to be a harder rule moving forward.

[bentsherman]

But why are you setting containers in this way? Do you need to have different containers for different process aliases?

[awgymer]

So it's mainly just a convenience factor as I set my all my per-process config using fully qualified or partially qualified names to ensure I don't accidentally apply config to something that has been aliased when I didn't mean to and for processes which in reality only exist once I don't want to define two separate withName blocks.

Secondly there are situations where you might want to have different container versions for different aliases - although I accept it would be quite niche right now. An example would be tools such as VEP for which there are different images for different database versions and maybe you want to use both independently in the pipeline.

Another situation where this comes in to play is if a pipelines defines a container in a withName: <PROCNAME> block and the user wants to override this, the only way to do so without editing the pipeline code is to define it in a withName: <FULLY_QUALIFIED_PROCNAME> block.

It's not a hill to die on for me but I designed my workflows (in the development sense not the nextflow sense) around the old behaviour.

[awgymer]

Is this the same issue that was fixed in #6736?

[bentsherman]

It should fix the cases where the withName selects the base process name. I don't think it fixes the case of fully-qualified names or aliased names. I might be able to solve that piece at some point in the future