WIP: a builder API for pip extension 1/n - platform defs

[aignas]

This is just some stuff that I wanted to write down before I forget. Feel free
to continue/hack on this.

The goal is to have:

• platform_version configuration for the users.
• Support users telling us the preference of which wheels should be used.
• Support users customizing the env markers for the requirements.txt
  evaluation. In the future the same API should be good enough for uv.lock
  and py.lock files.
• Support arbitrary platform definitions - by default rules_python will only
  care about the top 2 tiers of the supported platforms, but users should be
  able to customize things.

Work towards #2821
Work towards #2747
Work towards #2548
Work towards #1708

[rickeylev]

Suggested change

	:::{versionadded} 1.4.0
	:::{versionadded} VERSION_NEXT_FEATURE

[rickeylev]

I think I'm following the idea here. Basically, right now you can do:

pip.parse(requirements_by_platform={
  "linux*": "requirements_linux.txt",
}, ...)

And it uses the PLATFORMS values for what is defined as "linux".

The idea here is to move those definitions into the bzlmod API calls:

pip.default(
  platform="my-platform",
  ...
)

pip.parse(requirements_by_platform={
  "my-platform": "requirements_linux.txt",
}, ...)

And now instead of using the PLATFORMS global, it'll use that pip.default() information.

Ok, mostly LGTM so far. Under the hood, I can imagine:

pip.default(platform="linux_glibc", ...)
pip.default(platform="linux_musl", ...)
pip.parse(requirements_by_platform={
  "linux_glibc": "requirements_a.txt",
  "linux_musl": "requirements_b.txt",
}, ...)
# -> generates a BUILD file like
alias(
  name = "foo"
  actual = select({
    ":is_linux_glibc": "@requirements_a//foo:foo",
    ":is_linux_musl": "@requirements_b//foo:foo",
  })
)

Am I imagining the same as you?

Questions:

• What can this express that env markers can't? i.e. why would one do this instead of creating a requirements.txt with foo; os_name="my-platform-os" (I might have answered this with my example above -- I don't think "musl" can be expressed by env markers?)
• This seems to create a duplicate mapping of platform names and their metadata (presumably, the python.toolchain() APIs won't be entirely able to not use the platform keys). Is this the part you were mentioning in the recent issue?
• Does this need to feed into the simple-index-url walking? The part I'm thinking of is how it maps wheel names to the config the wheel supports.
• In the example above, all we actually need is a config_setting label. The user could pass that in directly.