conda-lock picks up the wrong sys_rc_path

[ctcjab]

Checklist

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

What happened?

conda-lock bundles its own, vendored version of conda. conda calculates the sys_rc_path (i.e., the system-global condarc) based on sys.prefix.¹

As a result, conda-lock will not pick up the same global condarc as conda, unless conda-lock happens to be installed in conda's own base environment.

Often, conda-lock is installed in a different environment, such as when installed via pixi global, or via a pre-commit hook (as shown in #237 (comment)). In general, it's better to install a global devtool like conda-lock in its own private isolated environment that tools like pixi global can manage for you, rather than put them in conda's base environment, which can result in corrupted or harder-to-upgrade, more error-prone conda installations.

This discrepancy is especially challenging when the global condarc needs to contain config like channel_alias: https://artifactory.mycompany.com/... and channels: [mycompany-internal-channel] (that ideally should not need to be duplicated in every user's ~/.condarc on every host to work around this -- better to keep these settings that user's should not be able to change in a global config file that is not user-writable). When conda-lock has a different sys.prefix and does not pick up this expected global config, solving fails and it is unable to generate lockfiles.

Can conda-lock add logic to detect when its vendored conda's sys.prefix does not match that of the user's conda (i.e., the one that gets resolved based on the user's PATH), and in this case patch in a corrected sys_rc_path value?

Footnotes

1. See here for where this happens in the latest release, and here for a more recent, not-yet-released version. ↩

[maresb]

Thanks @ctcjab for the well-written issue!

For your case, would it make sense to place the .condarc not under sys_rc_path but rather under an actual global search path, e.g. /etc/conda/condarc.d/?

[ctcjab]

I changed from /opt/conda/.condarc to /etc/conda/condarc and it fixed this. Thanks for the hint, @maresb!

I have filed jupyter/docker-stacks#2173 so that other users of these common base images will hopefully not hit this in the future the way I did.

[maresb]

Great, thanks for the follow-up!

Then this can be closed, right?

[minrk]

Updating from the docker-stacks report: it is the standard $CONDA_ROOT condarc location that's being ignored. So I think it's up to conda-lock to decide if it is right to ignore the condarc for the conda install of conda-lock itself, but I would consider it at least surprising and perhaps a bug that invoking conda and conda-lock in the same env produce different results. If it's not a bug, it should probably be documented deliberate behavior that your conda config is ignored by conda-lock (but only root config, not current env config, and only if the current env is not the root env, if I've understood the report correctly, which makes me think it's a bug).