[>=25.02.0-edge] unable to resolve class nextflow.script.ScriptParser

[rcannood]

Bug report

Hi all!

With Nextflow >= 25.02.0-edge I get the following error:

NXF_VER=25.02.0-edge \
  nextflow run czbiohub-sf/utilities \
  -r 0.1.3 \
  -main-script target/nextflow/tabula_sapiens/concat/main.nf \
  --help

 N E X T F L O W   ~  version 25.02.0-edge

Launching `https://github.com/czbiohub-sf/utilities` [big_monod] DSL2 - revision: ebc700cf69 [0.1.3]

ERROR ~ Script compilation error
- file : /home/rcannood/.nextflow/assets/czbiohub-sf/utilities/target/nextflow/tabula_sapiens/concat/main.nf
- cause: unable to resolve class nextflow.script.ScriptParser
 @ line 1419, column 1.
   import nextflow.script.ScriptParser
   ^

1 error


 -- Check '.nextflow.log' file for details

This is because nextflow.script.ScriptParser was renamed to nextflow.script.parser.v1.ScriptLoaderV1 in #4613.

Is there a way for Nextflow to be backwards compatible, e.g. by adding:

package nextflow.script

import nextflow.script.parser.v1.ScriptLoaderV1

class ScriptParser implements ScriptLoaderV1 {}

Otherwise organizations which are using production workflows on seqera cloud will end up with broken workflows when Nextflow is automatically updated to a newer version.

Thanks!
Robrecht

Expected behavior and actual behavior

With an older version of Nextflow, this error does not occur:

NXF_VER=25.01.0-edge \
  nextflow run czbiohub-sf/utilities \
  -r 0.1.3 \
  -main-script target/nextflow/tabula_sapiens/concat/main.nf \
  --help

concat 0.1.3

Inputs:
    --id
        type: string, required parameter
        example: sample
        ID of the sample.

    --input
        type: file, required parameter, file must exist
...

Instead, I get the error shown above.

Steps to reproduce the problem

See above.

Program output

See above.

Environment

• Nextflow version: 25.01.0-edge
• Java version: 21.0.6
• Operating system: Fedora 40
• Bash version: 5.2.26

Additional context

(Add any other context about the problem here)

[bentsherman]

These classes are internal and not guaranteed to be stable across releases. In fact, they are not even guaranteed to be accessible in Nexflow scripts.

I suggest moving such code into a plugin so that you can better control the version of Nextflow that it depends on.

[rcannood]

I see your point -- but at the same time in #4869 you were considering exposing it as an extension point, acknowledging that it would be useful for community members to work with this class 😅

I'm actively looking into refactoring much of our code into a plugin. However if the current implementation of Nextflow is released as a stable version it would break a lot of production workflows in different large organizations, some of which I know are direct Seqera clients.

Is it possible to consider introducing a fallback, until we've had the time to develop a decent Nextflow plugin, and make sure that clients have transitioned successfully to the new implementation?

Thanks for your help :)

[bentsherman]

To be fair, #4869 would almost certainly involve breaking changes to internal classes, even if the end result would be stable.

I can't control how others extend Nextflow, but it's simply not reasonable for us to preserve all internal APIs or maintain fallbacks for every change, just because someone else might be using that internal class in their scripts. It's a side effect of the fact that you can basically import anything from the Nextflow runtime into a Nextflow script... but we are trying to get away from that 😅

I would also point out that a new stable release only breaks your setup if you choose to upgrade to it -- but no one has to upgrade immediately! We try to make the upgrade as smooth as possible, but we make no guarantee that it will always be 100% seamless