"Illegal ambiguous match" error with experimental_index_url

[tbarrella]

🐞 bug report

Affected Rule

pip.parse

Is this a regression?

not sure

Description

When pip.parse with experimental_index_url uses per-platform requirements files and package versions don't match across files, it's possible (at least on OSX, for some packages) that using the package fails with "Illegal ambiguous match"

🔬 Minimal Reproduction

https://github.com/tbarrella/ambiguous

🔥 Exception or Error

Illegal ambiguous match on configurable attribute "actual" in @@rules_python++pip+pypi//debugpy:pkg:
@@rules_python++pip+pypi//_config:is_cp313_py_none_any_osx_aarch64
@@rules_python++pip+pypi//_config:is_cp313_cp313_osx_universal2
Multiple matches are not allowed unless one is unambiguously more specialized or they resolve to the same value. See https://bazel.build/reference/be/functions#select.

Illegal ambiguous match on configurable attribute "actual" in @@rules_python++pip+pypi//tornado:pkg:
@@rules_python++pip+pypi//_config:is_cp313_sdist_osx_aarch64
@@rules_python++pip+pypi//_config:is_cp313_abi3_osx_universal2
Multiple matches are not allowed unless one is unambiguously more specialized or they resolve to the same value. See https://bazel.build/reference/be/functions#select.

🌍 Your Environment

Operating System:

  
macOS, M2, 15.3.1
  

Output of bazel version:

  
Bazelisk version: 1.25.0
Build label: 8.1.1
Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer
Build time: Tue Feb 25 18:53:44 2025 (1740509624)
Build timestamp: 1740509624
Build timestamp as int: 1740509624
  

Rules_python version:

  
1.3.0
  

Anything else relevant?

• The root cause may be the same as experimental_index_url can only be used in one pip.parse(), subsequent calls fail #2648
• Workaround is to manually make the versions and hashes match when possible

[aignas]

The root cause of this is different from #2648.

The reproduction is trying to include different versions for different target platforms and it seems that it is failing due to us including more than what would be minimally necessary. I was already thinking about the fix for this but did not have time to do it but in quick terms here is what I am thinking about.

---

First select_whls is returning a list of compatible wheels with the target platform.

1. the freethreaded/non-freethreaded
2. manylinux/musllinux
3. universal2 vs arch wheels

Instead of having all of them, we could just have one wheel that is matching the target platform.

However, the target platform definition is not customizable and in order to have it customizable, we have to first implement #2909. Once that is done, we can revisit this issue.

---

A workaround for this is to not use different versions for different target platforms or to remove the hashes for some of the requirements.

[rickeylev]

One trick to avoid ambiguous match is to use a chain of select-default, e.g

alias(
  name = "x" actual = select({
  ":ft_yes": ...,
  "//conditions:default": ":ft_no",
  })
)

alias(
  name = "ft_no", actual = select({
    ":linux": ...,
    ":mac": ...
  })
)

[aignas]

But to be fully correct we would have to first select the target platform and only then the wheel based config setting.

That would be another solution to this problem.