`conda-lock` will crash with a key error if `pip` is not included in the environment file on some platforms

[schuylermartin45]

Checklist

• I added a descriptive title
• I searched open reports and couldn't find a duplicate

What happened?

I am currently developing a new closed-source project that is using conda exclusively. I am not publishing this project on PyPi; I do not need pip in any capacity. I do not have a pyproject.toml. I am using conda and conda-lock to manage the environment within a Docker container.

When conda-lock is run from a GitHub Workflow container, I get a series of cascading KeyError exceptions. Here is a partially redacted log:

+ conda-lock -f environment.base.yaml -f environment.dev.yaml -p linux-64 -p linux-aarch64 --lockfile conda-lock.dev.yaml
Locking dependencies for ['linux-64', 'linux-aarch64']...
INFO:conda_lock.conda_solver:linux-64 using specs ['python 3.13.*', 'conda 25.7.0.*', 'pytest 8.4.1.*', ...]
Traceback (most recent call last):
  File "/home/runner/.local/conda/envs/test/lib/python3.13/site-packages/conda_lock/lockfile/__init__.py", line 34, in _seperator_munge_get
    return d[key]
           ~^^^^^
KeyError: 'pip'
...

I have not been able to reproduce this locally on my osx-arm64 machine or in a temp docker container. But if I add:

  # renovate: datasource=conda depName=main/pip
  - pip=25.2

to my environment file, the issue goes away from our GitHub workflow automation and conda-lock works just as before. All dependencies are marked with datasource=conda and we use conda-lock to setup our dev and prod containers. We have been able to run tests and execute code without pip in our containers.

pip is not (knowingly) installed in the PATH of either my local conda environment where I have run this lock file command, nor is it intentionally being installed in our GitHub workflow.

Thanks!

Additional Context

No response

[maresb]

Hey, apologies for the very delayed response on this.

Being able to crash conda-lock with a KeyError is definitely a bug.

pip is not (knowingly) installed in the PATH of either my local conda environment where I have run this lock file command, nor is it intentionally being installed in our GitHub workflow.

That's very curious because usually Conda injects pip as a dependency of python unless you actively disable the setting. Since this is rare, I could imagine that conda-lock doesn't properly handle it.

Could you check in your environment for this setting? To check, run this command and compare your output with mine:

$ conda config --show-sources
==> ~/.condarc <==
add_pip_as_python_dependency: False
channel_priority: strict
channels:
  - conda-forge
  - nodefaults

Normally, add_pip_as_python_dependency defaults to True and is unlisted in the config, but I temporarily added it to demonstrate the output.

[schuylermartin45]

Sure, and I guess this might explain why I couldn't reproduce the issue locally:

anaconda_anon_usage: True

==> /Users/smartin/.condarc <==
channels:
  - defaults
solver: libmamba

==> envvars <==
add_pip_as_python_dependency: False
allow_softlinks: False

I also have it disabled by default. I don't intentionally create a .condarc file in docker. Presumably I'm just inheriting the configuration from the continuumio/miniconda3 image I build off of.

Off the top of my head, I don't remember which workflow was causing this issue, but maybe it was using a conda install with the flag enabled(?)

I'll have to poke further when I have a moment. I definitely don't want my environments making an assumption. I really should investigate and force the flag to False everywhere I can.

[maresb]

Ah, thanks for checking that!

Looks like I need to add coverage for this setting and fix the bug.

[schuylermartin45]

I was able to solve my original issue by removing pip as a dependency and then configuring these environment variables in my automated workflows:

export CONDA_ADD_PIP_AS_PYTHON_DEPENDENCY=0
export CONDA_USE_PIP=0

Thanks for pointing me to that documentation, @maresb that saves us an unnecessary dependency!

[schuylermartin45]

(I will note that I added CONDA_USE_PIP=0 out of an abundance of caution; I don't think it actually does much for our use case)