Shall I push some of my thoughts as code or leave this at a comment level in the PR?

Yes, go ahead and push changes.

As I've poked around the various pep508.bzl files, I see there's a lot of little utilities, tests, edge cases, etc. I'm just plowing ahead and copy/pasting things. Feel free to point out specific places where something should be wired into something else

Ok, basic flag with tests is working.

Based on the convo in the other issue, it's pretty clear I didn't understand the jargon and renaming things is in order.

renamed to env_marker_setting, since it's all about evaluate env markers.

Saw this comment you added:

NOTE: Platform release for Android will be Android version:

I think there are android-specific flags in the android rules that could tell that info. However, we wouldn't want to depend on the android rules. If we want to cleanly support this, then a toolchain would probably be best. The way it could work is using toolchains in a plugin model type of way. Depending on the android rules runs their MODULE.bazel, which registers e.g. (toolchain_type=rules_python_platform_release, target_compatible_with=[android], target_settings=[@android//:version=X] value=X)

How is the extra env marker supposed to be evaluated? I'm having trouble finding an intelligible specification or example. All I've really found is extra == "pdf" as an example in pypa core metadata spec. So its a plain string? But there can be many extras? I don't get it.

Well, this started as a prototype, but it's actually functional now! PTAL

We could probably skip straight to analysis time dependency selection when the rest of the rest of the starlark pep 508 functionality is ready. I was trying to figure out how to re-activate those code paths for testing, but it wasn't immediately obvious.

How is the extra env marker supposed to be evaluated? I'm having trouble finding an intelligible specification or example. All I've really found is extra == "pdf" as an example in pypa core metadata spec. So its a plain string? But there can be many extras? I don't get it.

Yeah, extra is just a string and it never is a version, so != and == in theory should be enough. However, expressions with extra should never passed to this marker_setting.

Well, this started as a prototype, but it's actually functional now! PTAL

We could probably skip straight to analysis time dependency selection when the rest of the rest of the starlark pep 508 functionality is ready. I was trying to figure out how to re-activate those code paths for testing, but it wasn't immediately obvious.

Regarding this, I think you are right, we should go straight to analysis time. My thinking is that we need to have a list of deps that the hub repo has. Instead of target_platforms just have a list of whl names. Once we have Requires-Dist list, process extra conditions in the expressions and combine the expressions so that we have one expression per package. filter out the requires dist so that it only contains the dependencies from deps, so that bazel query still works. Generate extra targets using what is in this PR.

Yeah, extra is just a string and it never is a version, so != and == in theory should be enough. However, expressions with extra should never passed to this marker_setting

My 2c is that extras are more appropriate for to be passed as flags.

And markers are more appropriate to be mapped from platforms.

Extras are generally user provided and markers are generally build system / environment provided.

I pulled out the newly added flags soas not to affect the public API for now. PTAL

I'll send a separate PR to factor out a common "env marker config" thing, as described in #2826 (comment)