Chris Burroughs

Heeding advice and deferring `--pin` for now. I *think* `_setup_pip_args_and_constraints_file` and `pex` itself handles all of the footguns and it is okay to pass along `--project` without a lot of...

Possible along the same lines of #18391?

For the specific case of in-repo plugins it would be really spiffy if this provider could be enabled conditionally. (per target? per python version?) That would make the "hermetic python"...

I'm a little unsure how having a platform flag in the form would work with (`resolves_to_target_platforms={linux,mac}`) would work with what PEP 508 calls `platform_machine`. I think it would be reasonable...

By "middle layer", you mean that that pex can take an ergonomic flag like `--target-system` for the `platform_system` (in PEP 508 terms), or any combination of markers you want with...

Unsure if this is orthogonal or a "happy accident" ontop of the underlying issue, but in https://github.com/pantsbuild/pants/discussions/20368 I'm relying on `"3rdparty/py` acting as a dependency of the entire lockfile.

After thinking about this more, I'm not sure this is feasible without Pants having a much better sense of the transitive dependency graph a la #12733. If a transitive 3rdparty...

On the design front here. I think for the original use case (which I share) of unit vs other type of tests, the opt-in would need to be per goal....

What does this PR need to move forward?

cc @franciscojavierarceo per dev call