nextflow VS Airflow

> It's been a while since you can rerun/resume Nextflow pipelines

Yes, you can resume, but you need your whole upstream DAG to be present. Snakemake can rerun a job when only the dependencies of that job are present, which allows to neatly manage the disk usage, or archive an intermediate state of a project and rerun things from there.

> and yes, you can have dry runs in Nextflow

You have stubs, which really isn't the same thing.

> I have no idea what you're referring to with the 'arbitrary limit of 1000 parallel jobs' though

I was referring to this issue: https://github.com/nextflow-io/nextflow/issues/1871. Except, the discussion doesn't give the issue a full justice. Nextflow spans each job in a separate thread, and when it tries to span 1000+ condor jobs it die with a cryptic error message. The option of -Dnxf.pool.type=sync and -Dnxf.pool.maxThreads=N prevents the ability to resume and attempts to rerun the pipeline.

> As for deleting temporary files, there are features that allow you to do a few things related to that, and other features being implemented.

There are some hacks for this - but nothing I would feel safe to integrate into a production tool. They are implementing something - you're right - and it's been the case for several years now, so we'll see.

Snakemake has all that out of the box.

For now, I think that the best place to track this / get your voice heard is this GitHub Discussions post (which covers many things - error reporting is one of them). https://github.com/nextflow-io/nextflow/discussions/3107

We could spend the day pointing to things we wish were different, but that doesn't change the fact that Nextflow is the leader when it comes to workflow orchestration. And feel free to create a new issue in the GitHub repository if you wish to request a feature :)

The nextflow devs have been talking about this for a while on GitHub. Looks like they're implementing something along these lines using schema like they do for nf-core. GitHub discussion.

Groovy definitely scales up just fine I think but I never used it myself outside of little snippets embedded in my DSL, I know its considered by some to be "dead" so its interesting to see what other JVM-ecosystem users think of it.

Contributing to Apache Airflow's open-source project immersed me in collaborative coding. Experienced maintainers rigorously reviewed my contributions, providing constructive feedback. This ongoing dialogue refined the codebase and honed my understanding of best practices.

In week Two, I contributed to the Apache Airflow repository.

Apache Airflow is an open-source platform to programmatically author, schedule, and monitor workflows. The platform features a web-based user interface and a command-line interface for managing and triggering workflows.

Airflow is the most widely used and well-known tool for orchestrating data workflows. It allows for efficient pipeline construction, scheduling, and monitoring.

AIRFLOW This is more of a library in my opinion, but Airflow has become an essential tool for scheduling in my work. All our ML training pipelines are ordered and scheduled with Airflow and it works seamlessly. The dashboard provided is also fantastic!

I agree there are many options in this space. Two others to consider:

- https://airflow.apache.org/

- https://github.com/spotify/luigi

There are also many Kubernetes based options out there. For the specific use case you specified, you might even consider a plain old Makefile and incrond if you expect these all to run on a single host and be triggered by a new file showing up in a directory…

You can try and contribute some new connectors/operators for workflow managers like Airflow or Airbyte