Ah yes, the sdist repos need to be prefixed/suffixed with the python version. The fix should be reasonably easy - only the repo name should be updated.

PRs are welcome here if someone needs this before I can take a look at it.

Thanks for the quick response. Making a reproduction was more difficult than I expected.

I'm assuming you mean somewhere in the following lines, is that right?
https://github.com/bazelbuild/rules_python/blob/a816962e509311c23230730b4b28f9d52a229949/python/private/pypi/whl_repo_name.bzl#L36

Yes, exactly. I think passing python_version to that function would be enough. Using something like python_version.replace(".", "_") would be a sufficient suffix to not cause clashes, but still work (beware, there should not be any . in the name or the python importing machinery gets angry).

For reference this comment was wrong, it is unclear yet why this is happening.

More debug information on the 2nd sdist, logged on the line:https://github.com/bazelbuild/rules_python/blob/e7d2f09394dd14816310c4c661d2fefab33b2b1b/python/private/pypi/extension.bzl#L246

 repo_name:  third_party_python_base_311_python_bidi_sdist_0665a082
 whl_name:  python_bidi
 args:  {"repo": "third_party_python_base_311", "dep_template": "@third_party_python_base//{name}:{target}", "python_interpreter_target": Label("@@rules_python~~python~python_3_11_host//:python"), ..., "requirement": "python-bidi==0.6.0", "urls": ["…pi/packages/packages/42/72/798318217bf0ee8e68af67e6e23c5e1017b9ab83b96019bf240da7b7a72f/python_bidi-0.6.0.tar.gz"], "sha256": "0665a0826074a9ff8d29640c0c405a2710b671db14fcc8b1c3ee6615ff10b837", "filename": "python_bidi-0.6.0.tar.gz", "experimental_target_platforms": ["cp311_osx_aarch64", "cp311_osx_x86_64"]}
 config_setting:  struct(config_setting = None, filename = "python_bidi-0.6.0.tar.gz", target_platforms = ("cp311_osx_aarch64", "cp311_osx_x86_64"), version = "3.11")

 repo_name:  third_party_python_base_311_python_bidi_sdist_0665a082
 whl_name:  python_bidi
 args:  {"repo": "third_party_python_base_311", "dep_template": "@third_party_python_base//{name}:{target}", "python_interpreter_target": Label("@@rules_python~~python~python_3_11_host//:python"), ..., "requirement": "python-bidi==0.6.0", "urls": ["…pi/packages/packages/42/72/798318217bf0ee8e68af67e6e23c5e1017b9ab83b96019bf240da7b7a72f/python_bidi-0.6.0.tar.gz"], "sha256": "0665a0826074a9ff8d29640c0c405a2710b671db14fcc8b1c3ee6615ff10b837", "filename": "python_bidi-0.6.0.tar.gz", "experimental_target_platforms": ["cp311_linux_aarch64", "cp311_linux_arm", "cp311_linux_ppc", "cp311_linux_s390x", "cp311_linux_x86_64"]}
 config_setting:  struct(config_setting = None, filename = "python_bidi-0.6.0.tar.gz", target_platforms = ("cp311_linux_aarch64", "cp311_linux_arm", "cp311_linux_ppc", "cp311_linux_s390x", "cp311_linux_x86_64"), version = "3.11")

Key part is that the experimental_target_platforms from args and target_platforms from config_setting differ for the same sdist file.

Is there a bug in parse_requirements.bzl? Hmmm. I think I may know what is happening.

1. The requirements.txt files for the darwin and linux have different lines for the bidi package. Could you paste them here?
2. Because they are different, the logic in requirements.txt will think that all of the shas for each platform are unique, but in sdist they are not.

I think we need to fix the parse_requirements.bzl logic to not make assumptions and do the merging of the requirements.txt sources in a more clever way. This has unit tests, so should be doable.

Another option is to handle this at the extension level where the extension is not blindly creating sdists, but that option is less appealing to me because the former is easier to test.

1. The requirements.txt files for the darwin and linux have different lines for the bidi package. Could you paste them here?

Yes, this was exactly the issue. The lines are slightly different, with one hash appearing on darwin lock file but not linux linux lock file, and one hash appearing on linux but not the darwin.

When I initially tried to create the reproduction, I wasn't using the exact same set of hashes as my main repo.
I've updated the reproduction now (requirements_3_11.txt and requirements_3_11_darwin.txt are now different in terms of hashes) and it's showing the same error, https://github.com/chrisirhc/rules_python-repro-multiple-exp/

Took a stab at fixing it via #2658 but looks like it breaks some behavior on mac/universal, and any whls. Potentially due to extension.bzl's handling. Let me know what you think.