I also had work targeting 2.23 I am working on today regarding what we said we would do in https://www.pantsbuild.org/blog/2024/08/24/venerable-pythons that

Ah, sorry to relitigate (I think I missed prior discussion), but that sounds like the plan is to do a hard-break, where users using the tools with 3.7 now will hard-fail when they upgrade to 2.23 (no soft-deprecation)? Have I misinterpreted?

Correct. (Or put another way the notice is the blog/notes instead of stdout.)

Ah okay. Would it be hard to convince us to deprecate in 2.23 and then remove in 2.24? That still seems inline with the blog post?

If the implication is "cut releases on time; don't block for features" it would probably be good to be stricter about that and I won't argue the point. If the idea is that people need even more time I'm skeptical; 3.7 was EoL back in 2023 (I say this as someone who has a locked on 3.7 production app.)

Oh, no, I'm more thinking "avoid hard deprecations where we can", and I'm not sure a blog post people may not see is quite as a good as an in-code/active one

hmm, what's the detectable "deprecation" mechanism?

[python].interpreter_constraints

?

Good question. Thinking out loud: • I think the feature we're deprecating here is a tool being executed with Python 3.7 when using the built-in lockfiles • So, I guess we'd want to detect when a tool's pex is being with those conditions (i.e. using a built-in lockfile and an actual Python 3.7 interpreter, not just ICs that include it) • I'm not sure that's particularly feasible, so maybe we just have to cut our losses and just rely on release notes and blog posts

At least there is an easy escape - generate your own lockfiles

re 3.7 --> https://github.com/pantsbuild/pants/pull/21389 (not as simple as I thought!)