Repository navigation
Adopt conda-ship Fleet for managed tool lifecycles #373
Description
Problem or motivation
ana currently installs its managed tools from embedded lockfiles with a direct Rattler implementation. Draft PR #322 evaluated conda-ship's Fleet API as an alternative, but the proof of concept is no longer mergeable and does not preserve the existing tool lifecycle.
The current proof of concept:
- derives the runtime delegate and requested package specs from exposed launcher names
- selects
anaconda-clias the delegate even though that tool is invoked asanaconda - parses versions from package filenames in a way that fails for hyphenated package names
- disables lock-change updates
- treats any existing prefix directory as an installed tool
- does not exercise the Fleet feature in CI
We need one explicit adoption decision backed by the real managed-tool lifecycle.
Proposed solution
Refresh or replace PR #322 against current main and use Fleet as the managed-tool backend if it can preserve the current behavior. Keep catalog policy, migration, launcher ownership, prompts, and telemetry in anaconda-cli.
The implementation should:
- model runtime id, version, delegate executable, requested package specs, exposed commands, exact condarc, frozen-base policy, installer provenance, and update policy as separate catalog fields
- construct
RuntimeSpecfrom each embedded resolved lock without inferring package metadata from launcher names - compare the selected lock digest with
InstalledRuntime.lock_sha256and request a forced reinstall only when reconciliation is required - use Fleet metadata for installed-state and corruption checks
- use Fleet command and PATH data when invoking managed tools
- preserve explicit downstream ownership for Unix links, Windows shims, wrappers, and their removal
- define safe migration and failure behavior for prefixes created by the existing Rattler backend
- prove install, command execution, list, lock-change update, interrupted or corrupt-prefix recovery, migration, uninstall, and launcher handling across the release operating-system matrix
If this work finds a lifecycle step that the current Fleet contract cannot express, open a narrowly scoped conda-ship issue with the failing consumer case.
Alternatives considered
- Keep the direct Rattler implementation. This remains the fallback if Fleet cannot preserve the lifecycle without adding complexity.
- Maintain both backends behind a long-lived feature flag. The proof of concept shows that this duplicates lifecycle behavior and lets the two implementations drift.
- Add more Fleet APIs before exercising the consumer. Most of the current gaps are in the
anaconda-clicatalog and lifecycle integration, while Fleet already exposes installation, metadata, command, PATH, and shim-plan primitives.
Additional context
- Fleet proof of concept: feat: Add experimental fleet feature for conda-ship tool installation #322
- Managed conda work stacked on the proof of concept: feat: Add conda as a managed tool #323
- Current corrupt-install repair work: fix: Detect corrupted tool installation when binary is missing (CLI-678) #366
- Upstream Fleet end-to-end readiness: Test Fleet with stamped runtime artifacts conda-incubator/conda-ship#51
- Fleet contract: https://github.com/jezdez/conda-ship/blob/main/docs/explanation/fleet.md
Activity
Yash990-bit commentedon Sep 12, 2026
Hi @jezdez, I’d like to work on this issue and investigate the adoption of Fleet for the managed-tool lifecycle.
I can start by reviewing the current managed-tool implementation and the Fleet contract, then update the existing #322 approach against
mainand verify the required lifecycle behavior.Would it be okay if I take this up and propose a PR?