Validate a workspace lock against its manifest

Watch the Discover, solve and maintain a workspace demo and follow the commands below.

Use a saved workspace conda.lock to check whether every declared environment and target still satisfies its manifest. This is useful after changing dependencies or channels and before accepting a lock in CI. Start with the conda.toml and combined lock from Parse and solve a workspace manifest.

Check the saved lock

Run the check with both input files:

conda presto --validate --file conda.lock --manifest conda.toml

The standalone conda-presto command accepts the same options. The manifest can also be a supported pixi.toml or pyproject.toml. Keep the saved lock’s filename conda.lock so the parser selects the workspace lock format.

The JSON report contains an overall consistent flag and one result for every environment and logical target. Each result identifies its environment, platform and concrete conda subdir. A consistent target has consistent: true and reason: null. A mismatch has consistent: false and a reason describing the first unmet check. Workspace-wide declaration mismatches can appear in several target results and name another affected environment.

Logical targets remain separate even when they share a concrete platform. The check uses the target’s declared virtual packages rather than the host’s detected capabilities. Environment and platform selectors are rejected so a passing result covers the whole manifest.

Detect a manifest change

In the example manifest, change the Python requirement from 3.13.* to 3.12.* without regenerating the lock. Repeat the check. It returns a JSON report with mismatching targets and exits with status 1 because the saved Python records no longer satisfy the declaration. Restore the original requirement or regenerate the lock deliberately, then run the check again.

The command leaves both files unchanged. It does not solve, fetch repodata, download archives, install packages or run workspace tasks. Additional package specs and channel overrides are rejected because the comparison uses the supplied manifest’s requirements and channels.

Use the exit status in CI

Save the report while preserving the command’s result:

status=0
conda presto --validate --file conda.lock --manifest conda.toml \
  > lock-check.json || status=$?
cat lock-check.json
exit "$status"

Exit status 0 means every target is consistent. Status 1 means the check completed and found mismatches, with details in lock-check.json. Status 2 means the inputs could not be checked, for example because they are malformed, unsupported, unreadable or exceed the parser deadline. Those errors go to stderr and do not produce a JSON report.

What the check covers

Presto calls conda-workspaces’ check_lockfile_satisfiability() with an environment selector for each declared target. Workspaces compares requirements, channels, package dependencies, constraints and virtual package requirements against the saved records. Conda’s MatchSpec, channel and package record APIs supply the underlying conda semantics. The environment selector is available in conda-workspaces 0.10.0 and later, required by Presto. No additional provider is required.

Virtual package versions come from the target’s system requirements, falling back to Presto’s configured operating system baselines. Host CPU and GPU detection is disabled. See Environment variable reference for the baseline settings.

Only self-contained conda package records are supported. PyPI dependencies, external package references and archspec system requirements fail as unsupported input. A passing result does not establish that packages are current, that downloaded payloads match their metadata or that the environment has no vulnerabilities.

The same operation is available through POST /validate for systems that use Presto remotely.