nextflow-io / nextflow-io/language-server

LSP command to list config profiles

Open
#133 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Java
Stars
31
Forks
8
Avg merge
1d 10h
Merged PRs (30d)
2

Description

External systems like Seqera Platform want to know the set of available config profiles for a Nextflow pipeline so that they can provide a drop-down list and check for typos.

The platform currently uses a custom static analyzer to detect config profiles without loading the config (executing code). It supports the cases documented here.

I would like to remove this custom analyzer and implement it in the language server instead. It should be possible via executeCommand:

https://github.com/nextflow-io/language-server/blob/cf6ee9abb4011c0073496771fd29985feb609507/src/main/java/nextflow/lsp/NextflowLanguageServer.java#L546

I think the LSP client will need to provide (1) a URL to a Nextflow pipeline repo or config file and (2) a map of launch params

Detecting config profiles in a single file is easy enough -- just look for the profiles block and get the name of each child block. The tricky part is detecting profiles from included files.

The analyzer needs to be able to handle dynamic config includes such as ternary expressions and param references -- this logic is already in platform and can simply be ported over.

The language server also needs to be able to download included files, including remote files, which may require authentication. It may be possible to facilitate this through LSP requests -- the custom command could use some internal protocol in the request/response to allow the server and client to exchange and request information recursively:

  1. platform requests profiles given a URL/params
  2. language server responds with some request ID and provides the included URLs it needs
  3. platform requests again with request ID and provides requested file content
  4. language server does not encounter any more includes, responds with final result

Alternatively, we could enable the language server to access the same authentication layer used by platform. It would make the language server JAR bigger but maybe the requests wouldn't take as long. At the same time, if the language server and platform are running in the same network, request latency should be low anyway.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at src/main/java/nextflow/lsp/NextflowLanguageServer.java near the executeCommand implementation. Review how the platform currently detects profiles and how dynamic config includes, remote files, authentication, and launch parameters need to be represented. Done means the language server exposes a command that returns profiles for the requested pipeline or config, including profiles discovered through included files.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
api, devtools
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.