check `conda list` before installing a package

[rootsmusic]

What's the problem this feature will solve?

When my PC runs a .ipynb file that I didn't create, some files (especially those with multiple parts) have installation commands in later cells. When I run all cells, !pip install or piplite.install commands will run if they're in a later cell. Since I'm running within a conda environment, these commands would still install duplicative packages (except from the pypi channel).

When these commands installs a duplicative package while running all cells, there's no indication that it's doing so. After these commands install a duplicative package, the newly installed package from pypi isn't shown in conda list.

Describe the solution you'd like

I'd like pip and piplite' to check conda list` to see if the package has already been installed from other channels.

Alternative Solutions

At least indicate that pip is (or has just finished) installing a package.

Additional context

#8415 is out-of-scope.

Code of Conduct

• [X] I agree to follow the PSF Code of Conduct.

[pfmoore]

If conda is installing packages with the correct metadata, then pip should recognise them. So either this is a problem with conda not following the relevant standards, or there is something else causing pip to not see the installed packages. Either way, it doesn't immediately seem like it's a pip issue.

[rootsmusic]

@pfmoore wrote:

there is something else causing pip to not see the installed packages.

I think my issue occurs when the latest versions aren't aligned between pypi and conda-forge. So pip would still install pypi's latest version, despite the existing version from conda-forge being the latest available from that channel. But pip doesn't first uninstall the existing version from conda-forge. Shouldn't pip know that it's being called within a conda environment?

P.S. I've added an "Alternative Solution" in my original issue.

[notatallshaw]

If the conda package maintainer is following best practises building the Python package then everything should "just work"*.

You're going to need to give a reproducible example rather than a general workflow to get any assistance. And likely the answer is going to be that it's not a bug with pip or something pip can solve, but that you should file an issue with the conda recipe.

---

^{* I'm sure there are edge cases}

[rootsmusic]

you should file an issue with the conda recipe.

@notatallshaw Yes, I agree that this issue isn't a bug. I opened it to request an enhancement, because I assume that pip isn't checking which packages have already been installed by conda. Are you recommending that I file an issue in conda-forge/staged-recipes or in a specific package's repo for builds? Thanks.

[notatallshaw]

Likely the specific package's repo, but it's been a little over two years since I spent time understanding the details of conda packaging and without specific details I'm speculating.

[ichard26]

I'm going to reject this feature request as it's the wrong solution to avoid conflicts between package installers. Either conda should take ownership of the Python environment using PEP 668 so pip will refuse to install to it, or conda should be following the relevant standards for installed distribution metadata so pip is able to find them and avoid the unnecessary installation.

Pip shouldn't have to special case for conda to play nice here. If all of the package installers are following the packaging specifications, it should just work.[^1]

[^1]: Barring bugs, obviously :p

[pradyunsg]

FWIW, we're also working with conda folks to get them to adopt PEP 668: https://github.com/conda/conda/issues/12245

[notatallshaw]

It should be mentioned, there is nothing stopping you from adding the PEP 668 externally managed marker manually, probably particularly useful if you maintain an Anaconda distribution in a company (as I once did) and putting it in the base environment.