Package directive

[evanroyrees]

Generic package directive with pluggable package providers

Summary

This PR continues the package-directive proof-of-concept from #6342, building it out into a
complete pluggable package-provider system. It adds a generic package process directive backed
by per-manager nf-<provider> plugins, so each package manager is an independent plugin rather
than a dedicated process directive:

process hello {
    package 'numpy pandas', provider: 'uv'

    script:
    """
    python -c 'import numpy, pandas'
    """
}

Lineage: picks up the conda/pixi PoC from #6342 (thanks @edmundmiller) and follows the
maintainer guidance there: a single generic directive with pluggable providers, aligned with
Wave, instead of per-manager directives (as discussed in #7023). New providers address
long-standing requests: nix and guix (#1526) and the R ecosystem via pak and install2.r
(requested in the #6342 review).

What's included

• Core enablement: the package directive under the v2 (strict) syntax parser, the
  nextflow.preview.package feature flag (script header or config), a packages config scope
  (packages.provider, packages.autoDetect), and manifest auto-detection. When a process has
  no package directive, the process module directory is scanned for a provider manifest
  (e.g. environment.yml, requirements.txt, pixi.toml), analogous to Wave's Dockerfile
  auto-detection.
• Five new provider plugins: nf-uv (Python venvs), nf-nix, nf-guix, nf-pak and
  nf-install2r (R), each implementing the PackageProvider SPI with its own environment
  cache, config scope, and unit tests. All create local-filesystem environments.
• conda/pixi providers extended and fixed: packaged extensions.idx so the extensions are
  actually discovered by pf4j, per-process options: override (folded into the environment
  cache hash), pixi fixes ([workspace] table, valid TOML dependency entries, host platform,
  .pixi marker handling), and removal of the PoC's duplicated CondaCache/CondaConfig
  copies (see design notes).
• Wave hand-off: explicit provider-to-Wave mapping.
• nf-test CI matrix: one job per provider, each provisioning its tool and running tagged
  nf-tests against a dev build.
• Docs: docs/package.md (in the toctree) plus entries in the config, feature-flags, and
  process references.
• ADR: adr/20260707-package-provider-plugins.md records the design decision (generic
  directive + provider SPI + plugins), the alternatives considered, and the conda-in-core
  rationale, following the ADR convention on master. It is marked proposed since you are
  the deciders. Happy to remove or rework it if you prefer the design discussion to live in
  this PR instead.

Design notes (deviations called out per the review guidelines)

• Parser change is minimal and v2-only. package is a Groovy/Java keyword, so it cannot be
  declared in the DirectiveDsl interface. The v2 AST builder stops rejecting package as an
  identifier (the PACKAGE lexer token was already disabled in ScriptLexer.g4), and the
  directive resolver allows it only in the process-directive section: it is still rejected
  as an input/output qualifier or in output {} blocks, with tests locking this in. The v1
  parser is untouched; the feature requires NXF_SYNTAX_PARSER=v2 and is gated behind
  nextflow.preview.package.
• Wave routing contract. Wave can only build conda-based environments, so conda, mamba,
  micromamba, and pixi map to Wave's CONDA build type, while local-only providers (uv,
  nix, guix, pak, install2r) skip Wave and are built locally by their plugin. Mixed
  pipelines work (conda processes built by Wave alongside uv processes created locally). No
  Wave functionality is added.
• conda stays in core (for now). The PoC copied CondaCache/CondaConfig into
  plugins/nf-conda, leaving two classes with the same fully-qualified name on different
  classloaders. This PR removes the copies: the plugin reuses the core classes that the legacy
  conda directive already depends on, and the per-process options override lives in the core
  CondaCache. Fully extracting conda into nf-conda is a natural follow-up once the legacy
  directive is deprecated.
• Config validation is wired end-to-end. Every provider scope (uv, nix, guix, pak,
  install2r, pixi) and the new packages scope implement ConfigScope and are registered
  in extensions.idx, so the strict config validator recognizes them instead of warning.

Why five providers in one PR

The SPI is only proven generic by implementations that differ structurally: uv (venv +
lockfile), nix/guix (store/profile model), pak/install2.r (language-level installers), alongside
conda/pixi (env-file model). Each plugin is small (~6 classes), isolated, and independently
testable; dropping any provider is a directory deletion. Happy to split if preferred.

Testing

• Unit tests for every new class (Spock), including per-provider cache/config/provider suites,
  parser scoping, feature-flag handling, Wave mapping, manifest auto-detection, per-process
  options overrides, and expected-failure cases. Full suite green locally (make test for the
  touched modules: nextflow, nf-lang, and all provider plugins).
• .github/workflows/package-providers.yml runs an nf-test job per provider (conda, uv, pixi,
  pak, install2r), provisioning each tool on the runner. nix and guix are excluded from CI
  because their store/daemon model does not provision cleanly on ephemeral runners; they are
  exercised via the demo workflows under tests/nf-test/examples/.

Limitations / follow-ups

• The feature is preview-gated and v2-parser-only by design.
• Spack provider (existing community interest), conda-lock support, and full extraction of
  conda from core are natural follow-ups.

All commits are DCO signed-off.