[Core] Add provision.conda_auto_activate config option

[lloyd-brown]

Summary

SkyPilot auto-activates the conda base environment on clusters that do not use a custom Docker image. This is convenient for conda-based workflows, but it makes base the implicit target of uv/pip commands run in setup/run scripts and interactive shells. For users who manage their own environments (e.g. uv-first projects), this is surprising: a uv pip install from a directory without a .venv silently installs into conda base instead of erroring or using the intended environment.

This PR adds a provision.conda_auto_activate config option so users can keep conda installed but not auto-activated.

• sky/backends/backend_utils.py: conda_auto_activate now honors provision.conda_auto_activate when set, falling back to the existing default (true, except false for custom Docker images).
• sky/skylet/constants.py: the post-install conda deactivate guard now also fires when conda_auto_activate is false. This is required because the install commands explicitly run conda activate base; without deactivating, base stays active in the chained provisioning shell and leaks into the Ray runtime (and therefore into user setup/run jobs), even though auto_activate_base is set to false for new shells.
• sky/utils/schemas.py: schema entry for the new option.
• Docs (config.rst) + a unit test.

Default behavior is unchanged.

Test plan

• Added tests/unit_tests/test_backend_utils.py::test_conda_installation_deactivates_base_when_auto_activate_disabled: asserts the rendered conda commands set auto_activate_base false and deactivate base when the option is false, while preserving the existing custom-Docker deactivate behavior.
• Manual: launched a Kubernetes cluster with provision.conda_auto_activate: false. Verified CONDA_PREFIX is unset and uv resolves cleanly (no longer binds to conda base) in both run commands and interactive SSH, and that a user-created .venv is used correctly. Verified that with the option unset, behavior is unchanged (base still auto-activated).

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces a new configuration option, provision.conda_auto_activate, allowing users to disable the automatic activation of the conda base environment on remote clusters. This is particularly useful for workflows that manage their own environments (e.g., uv-first projects). The changes include documentation updates, schema validation, backend logic to parse the config, and updates to the conda installation commands to deactivate the base environment when requested. Additionally, unit tests were added to verify this behavior. Feedback was provided to simplify the logic for determining the conda_auto_activate value in sky/backends/backend_utils.py to improve readability.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[kevinmingtarja]

One question, otherwise LGTM.

[kevinmingtarja]

Should conda_auto_activate: false also take effect on images that already have conda on PATH?

This whole block — including conda config --set auto_activate_base false — only runs in the which conda short-circuit:

skypilot/sky/skylet/constants.py

Line 253 in 0d69dc3

'which conda > /dev/null 2>&1 || '

So on an image where conda is already initialized and on PATH (e.g. the AWS DLAMI), which conda succeeds, the block is skipped, and auto_activate_base is never set to false. New interactive/SSH shells would then still auto-activate base, so the option silently has no effect there. (The in-shell→Ray leak isn't hit in that case, since we also never run our own conda activate base — it's the SSH/interactive path that's left exposed.) Worth handling that path, or at least noting the limitation in the docs?

[lloyd-brown]

Good catch, fixed in c79ce49. I moved the auto_activate_base setting out of the which conda short-circuit into a stanza that runs whenever conda is available (command -v conda), gated on the user having explicitly set provision.conda_auto_activate so we don't override conda config baked into custom images.

Validated live on a conda-already-on-PATH image (so the install block is skipped): the stanza fires and conda config --show auto_activate_base ends up false. Re-verified the default-image path for no regression.

One caveat I hit while testing, now noted in the docs: images that bake CONDA_PREFIX into the container ENV itself (e.g. continuumio/miniconda3) keep base as the implicit target regardless, since that's the image's environment rather than conda auto-activation. The DLAMI case you named activates base via conda init/auto_activate_base, which this handles.