build and release self-contained Pants scies

[cburroughs]

Plumbs through the most recent Pex scie flags for completeness and then uses them to build a Pex scie alongside the existing "regular" PEX. These are intended for early testing, but not to replace scie-pants or the current distribution model.

To wind way back up, the advantage of building a full scie as part of the Pants release:

• Easier major Python version upgrades instead of two step release dance.
• We can push out Python bugfix/security releases and control the minimum PBS version (ex: to pick up security updates)
• Simpler story for certain "no network" use cases..

But how that works with the current distribution model in a backwards compatible way requires further discussion.

This builds on all of the recent Pex releases that took this from plausible to possible to easy.

LLM Disclosure: A LLM generated the new test.

ref #22946

[cburroughs]

NOTE: Will need rebase after #23020 lands

[cburroughs]

(Leaving this as "Draft" until the dependent PR lands, but this is ready to look at.)

[jsirois]

I still contend this practice is insane. You muttered something about working well with defaults, but clearly there is a tension between defaults and tool coupling. Perhaps if defaults is a real reason, and not just post-hoc justification, making defaults work well with pass-thru-args style fields would be more sane and allow both decoupling from tools and supporting target defaults well?

[cburroughs]

I don't disagree that there is room for a better design for cases where tools have many options. (Or maybe a better design for all cases!) My appraisal is that that continuing the existing imperfect pattern is preferable to the growing entropy of an inconsistent state. If this is a situation (like metadata in lockfiles) where you have given an implementation suggestion multiple times, it is not ringing a bell for me and I'd appreciate if you pointed me to it. (You don't owe one of course, but I'd want to make sure I'm not missing context.)

I take you at your word when you say your comments are about code. But I'd like to suggest to you that "muttered" is sufficiently pejorative to strain credulity over the textual web.

[jsirois]

Muttered was intended to be perjorative indeed. The justification seemed in partially bad faith. You clearly understand the push pull but only highlighted the bright side. I appreciate a more level reasoning like you just gave. Call the shot - doing the thing not because best, but because reasons / best I can do for now. That's honest.

[jsirois]

I take you at your word when you say your comments are about code.

I'm surprised I said this. Some of my comments are about code, but I also am happy to comment on bad (or bad faith) reasoning when I see it. I have long done this. I do it internally with myself. Always call BS on yourself. It's the only place to start.