conda pypi is preferring conda channel over local converted channel

[ryanskeith]

Description:

During install it seem that conda pypi seems to not convert if there is a dependency available on a conda channel.

conda pypi install black
Inspecting pypi and conda dependencies
PYPI index channels:
 - https://pypi.org/simple/
Conda channels:
 - file:///Users/rkeith/Library/Application%20Support/conda-pypi
 - main
 - r
Converting required pypi packages: done
Installing environment
Retrieving notices: done
Channels:
 - file:///Users/rkeith/Library/Application%20Support/conda-pypi
 - main
 - r
Platform: osx-arm64
Collecting package metadata (repodata.json): done
Solving environment: done

## Package Plan ##

  environment location: /Users/rkeith/miniconda3/envs/cnda-pypi-dev

  added / updated specs:
    - black


The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    black-25.1.0               |   py39hca03da5_0         422 KB  main
    ------------------------------------------------------------
                                           Total:         422 KB

The following NEW packages will be INSTALLED:

  black              main/osx-arm64::black-25.1.0-py39hca03da5_0
  mypy_extensions    main/osx-arm64::mypy_extensions-1.0.0-py39hca03da5_0

The following packages will be UPDATED:

  ca-certificates                      2025.7.15-hca03da5_0 --> 2025.9.9-hca03da5_0
  certifi                           2025.8.3-py39hca03da5_0 --> 2025.10.5-py39hca03da5_0
  openssl                                 3.0.17-h4ee41c1_0 --> 3.0.18-h9b4081a_0


Proceed ([y]/n)? n

Suggested Resolution:

As the user is asking for something on a simple PyPI like index, they should be given it. The code needs to use the converted PyPI wheel if it exists.

[dholth]

Is that package file inside file:///Users/rkeith/Library/Application%20Support/conda-pypi?

The wheels-on-demand strategy is based on converting new wheels if there is a resolver error (package version not available). Easiest way at the moment is --override-channels to turn off normal channels. Or "black >= version-available-on-main". Maybe also "black[build string has pypi in it]" could be possible in conda-land?

conda list shows installed-by-pip packages as

unearth 0.17.3 pypi_0 pypi

but conda-pupa creates packages called id-1.5.0-pupa_0.conda for example; we would want to add a hash value to the build string to differentiate different wheels for the same version package.

So if you asked conda to install MatchSpec(name='foo', build='pupa_*') then it would be forced to use the "fallback to looking for wheels to convert" path.

[danyeaw]

I can reproduce this. I agree that conda pypi install --override-channels black will resolve it temporarily. I think this is unexpected though:

1. --override-channels should just force using only the simple index and no other channels
2. All packages explicitly provided should be from the simple index (or channel created from the index)

This would require modifying convert_tree() to pre-fetch the wheel packages, or doing some extra solve step or validation that we got the expecting packages from the index.

[ryanskeith]

@dholth , it looks like nothing happened:

tree /Users/rkeith/Library/Application\ Support/conda-pypi/
/Users/rkeith/Library/Application Support/conda-pypi/
├── channeldata.json
├── index.html
└── noarch
    ├── index.html
    ├── repodata_from_packages.json
    ├── repodata_from_packages.json.zst
    ├── repodata.json
    ├── repodata.json.zst
    ├── run_exports.json
    └── run_exports.json.zst

2 directories, 9 files