Nextflow Emacs Workflow

I was chatting with David at the recent Nextflow Summit in Boston about Emacs and comparing our various workflows. I thought I might turn this into a blog post after a question about Emacs workflows on the Seqera discourse.

When working with Nextflow and Emacs, my typical workflow involves having a local Emacs instance open with my project. I make changes to the source code within Emacs and run nextflow run . -profile test,docker ... in a separate terminal. I’ve tried integrated terminals in Emacs but it’s just always slightly off, so I don’t bother. Typically just have workspaces open with a Browser in workspace 1, Emacs in workspace 2, and a terminal open in workspace 3.

For projects that require a remote system, such as an HPC cluster, I utilize emacs-ssh-deploy. This tool automatically copies the file from my local machine to the appropriate directory on the server upon saving using sftp. To execute Nextflow, I simply ssh into the remote system and run nextflow run . -profile ... in a terminal.

I have considered developing a Transient-based launcher for nextflow-mode, similar to the one added to snakemake-mode. However, I have found these launchers to be fragile when dealing with terminal output. I even created one for the NodeJS framework, Jest, but have not used it extensively myself.

My goal is to keep my workflow simple and flexible, allowing for easy substitution of Emacs with other editors like Neovim, Helix, or Zed. As for my Emacs setup, I have been using Doom Emacs since 2018 ¹, and my .doom.d configuration is available on GitHub.

The Nextflow specific parts of my config:

(package! nextflow-mode :recipe (:host github :repo "edmundmiller/nextflow-mode"))

(use-package! nextflow-mode
  :config
  (set-docsets! 'nextflow-mode "Groovy"))