record environment intent in exported lockfiles

[jjhelmus]

Include details about the requested specs that were used to create an environment in the exported lockfiles.

[jaimergp]

Opened conda/conda#14821

[jezdez]

Status check: still open, not implemented.

Upstream piece is done: conda/conda#14821 (SolvedRecord) merged in May 2025, and conda.models.environment.Environment already carries a requested_packages field.

The gap is all on our side:

• conda_lock_v1_from_conda_envs in conda_lockfiles/conda_lock/v1.py builds the lockfile purely from env.explicit_packages. It never looks at env.requested_packages, and metadata.sources is hardcoded to [""].
• multiplatform_export in conda_lockfiles/rattler_lock/v6.py has the same shape: no intent serialized.
• Our own loader tests confirm it: tests/test_loaders.py asserts not spec.env.requested_packages on round-tripped lockfiles.

Picking this up as a follow-up to #131.

[jezdez]

Research follow-up before implementing.

Where the intent comes from: conda.history.History(prefix).get_requested_specs_map() returns dict[str, MatchSpec]. Environment.from_prefix(..., from_history=True) wraps that into Environment.requested_packages: list[MatchSpec]. Caveat: the default from_history=False populates requested_packages with every installed package (legacy conda env export behavior), so we need to either re-derive from history ourselves when env.prefix is a real prefix, or rely on callers passing from_history=True. Re-deriving is safer.

conda-lock-v1 storage: LockMeta is a pydantic StrictModel so new top-level or metadata.* fields get rejected by conda-lock itself. metadata.sources is specifically file paths (conda-lock's handle_no_specified_source_files treats them as such), abusing it for specs breaks interop. The one safe slot is metadata.custom_metadata, which is dict[str, str] | None upstream. Plan: store specs as a JSON-encoded string under a namespaced key like conda_lockfiles_requested_packages. Need to widen our own CondaLockV1CustomMetadata pydantic model from {created_by: str} to a free-form dict[str, str] to match upstream.

rattler-lock-v6 storage: rattler's lockfile deserializer does NOT use deny_unknown_fields, so pixi silently ignores extra keys. pixi install --frozen keeps working. The risk is on write: any rattler-driven re-lock (pixi add, pixi update) round-trips through the Rust data model and drops unknown fields. So the annotation is advisory, not durable across pixi workflows. Plan: add a per-environment requested-packages: {<platform>: [spec, ...]} map (kebab-case matches SolveOptions convention in rattler). Document the re-lock caveat.

No format-spec changes proposed. Both approaches are backwards-compatible and extension-style.

Test impact: tests/test_loaders.py lines 104 and 136 explicitly assert not spec.env.requested_packages; those will need to flip or be replaced by fixture-driven variants.

References:

• conda.history.History: https://github.com/conda/conda/blob/main/conda/history.py
• Environment.from_prefix: https://github.com/conda/conda/blob/main/conda/models/environment.py
• conda-lock LockMeta (StrictModel): https://github.com/conda/conda-lock/blob/main/conda_lock/lockfile/v1/models.py
• rattler-lock deserializer (no deny_unknown_fields): https://github.com/conda/rattler/blob/main/crates/rattler_lock/src/parse/deserialize.rs

Starting on the PR.

[jezdez]

Upstream issue filed to reconsider the from_history=False default: conda/conda#15961

In the meantime, the PR for this will re-derive intent from History(prefix).get_requested_specs_map() ourselves rather than trusting env.requested_packages, so we're not blocked on the upstream decision.

Also switching the lockfile key name from the originally proposed conda_lockfiles_requested_packages to just requested_specs — it matches CEP 32's terminology for lists of MatchSpec strings and conda-lock's custom_metadata has no namespacing convention.

[jezdez]

The custom_metadata: dict[str, str] constraint in CEP 37 is the reason the requested_specs value has to be a JSON-encoded string rather than a clean YAML list. Filed a discussion issue on conda/ceps to revisit that: conda/ceps#163

Not blocking for #132, but if the CEP amendment lands we can drop the JSON wrapper in a follow-up.