# Pip/conda compatibility

**URL:** <https://discuss.python.org/t/pip-conda-compatibility/24375>\
**Category:** Packaging\
**Created:** [February 25, 2023, 8:18am UTC](https://discuss.python.org/t/pip-conda-compatibility/24375 "2023-02-25T08:18:09Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![CAM-Gerlach](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cam-gerlach/32/3688_2.png) [@CAM-Gerlach](https://discuss.python.org/u/CAM-Gerlach)\
**Post date:** [February 25, 2023, 10:40am UTC](https://discuss.python.org/t/pip-conda-compatibility/24375/3 "2023-02-25T10:40:33Z")

</div>

Just to note, [conda/conda#12245](https://github.com/conda/conda/issues/12245) is currently open (as a result of initial discussion on PEP 704) to add an `EXTERNALLY-MANAGED` file to Conda’s `base` environment by default, to avoid pip breaking Conda/the conda installation itself.

> [@ncoghlan](#):
>
> if `conda` is currently providing `.dist-info/RECORD` files for the Python packages it installs, then dropping or renaming them would be one way to get `pip` and other tools to always leave conda-installed packages alone (however, I don’t know enough about conda’s mechanics to know if that might cause other issues, in which case the “split installation & import path” approach might be preferable)

That’s an interesting possibility to consider, as a middle ground for non-`base` environments. However, I would be inclined to think that it would be sufficiently disruptive to enough existing workflows that rely on `pip` updating packages that were originally `conda`-installed for various reasons (outdated conda package, updated dependency requirements by PyPI-only package, `pip install .`, etc.) that it might need to be at least opt-out if not opt-in at install time. There might also be other reasons why it’s a non-starter, not sure.

> [@ncoghlan](#):
>
> `conda` environments may want to implement a Linux-distro style split between the install location used for curated distribution packages and the install location used by Python-specific tooling (this means Python-specific tooling will at worst shadow the conda provided packages, and potentially not even that if the conda managed directories are given precedence over the Python-only ones)

There has been a lot of relevant discussion about this approach and the other mechanisms in general on the PEP 704 thread, [starting roughly here](https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/76). In general, the Conda folks seemed generally against this option as harming rather than helping Conda-pip interoperability, whereas the PyPA folks there believed it would help.

> [@ncoghlan](#):
>
> at a specification level, it’s worth considering whether the `EXTERNALLY-MANAGED` spec should be enhanced to allow runtime providers to select a “no native package installation” middle ground between “allow any packages (default)” and “disallow all packages (EXTERNALLY-MANAGED exists)”

I’m a little unclear what you mean here by “no native package installation” here. Could you explain further? I.e. by “no native” do you mean no non-pure-Python, no pip, no conda, or something else?

---

_[View the full topic](https://discuss.python.org/t/pip-conda-compatibility/24375)._