Got a question for the group about supporting Python 3.7 in tool lockfiles - we’ve had various issues like https://github.com/pantsbuild/pants/issues/21184 be filed to upgrade tools (in this case, a CVE for

setuptools

). However, in order to upgrade the tools or regenerate lockfiles with new versions of PEX/Pip, we’d have to drop support for Python 3.7 in the new lockfiles or find another way around the issue. Related issues: https://github.com/pantsbuild/pants/issues/20852, https://github.com/pantsbuild/pants/issues/20852, https://github.com/pantsbuild/pants/pull/21182, https://github.com/pantsbuild/pants/pull/21235 There are a couple ways I can see around this: 1. Create two separate lockfiles for each tool with different versions of PEX/Pip - one to support Python 3.7 and one to support Python 3.8+. Then infer which lockfile to use based on the interpreter constraints of the targets (?) 2. Drop support for running tools using Python 3.7 (not ideal) Does anyone here have thoughts on the best way to handle this?

Are you referring to upgrading the defaults in the Pants repo, or to upgrading just in your repo - you are always free to do the latter, if you don’t need Python 3.7 support

I mean the pants repo

Ah, yeah, that is a tricky one

I don't think separate lockfiles per Python version would be required, we would just need a separate lockfile for 3.7 as compared to 3.8+

Well, but that is just this specific case. We’re opening up a pandora’s box of version matrices in general…

Yeah, agreed there. I think that sunsetting 3.7 support is OK, since it's been EOL for over a year now. It also opens up a whole can of worms to try and support both older and newer versions of Python, as you point out.

Yeah, and to emphasize - Pants should still support it (we still support Python 2.7!), just not in its defaults.

Proposed announcement for dropping 3.7 support in bundled tools lockfiles: https://github.com/pantsbuild/pantsbuild.org/pull/251

Thanks for doing this! One of the problems I ran into when trying to fix the setuptools issue in the OP is that a lot of the backends/tools are interconnected with other parts of the codebase, so upgrading specific tools in isolation is actually more challenging that I thought. You can see an example of how this goes wrong here: https://github.com/pantsbuild/pants/actions/runs/10424380306/job/28873162650?pr=21314 Given this, we could either: 1. Enforce interpreter constraints of Python 3.8+ for all internal tests within the Pants repo 2. Set this effort aside for now and try to figure out a more robust way to continue to support Python 3.7 internally Any thoughts on which would work better?

Is 2.7 going with it?

I'm not sure, but most of the tests in question have interpreter constraints >= 3.7

Is 2.7 going with it?

Nope! If that was confusing from the blog post (as opposed to this thread) could you take a stab at a worksmith suggestion? The difference between "The Python version Pants can build/test" and "The Python versions in the default tool lockfiles" was the goal of the post!

Enforce interpreter constraints of Python 3.8+ for all internal tests within the Pants repo

I was leaning towards regenerating everything with >=3.8. I think there is value in being able to work with EOL Python code in Pants, but not in EOL code having a slick out of the box experience.

> Nope! If that was confusing from the blog post (as opposed to this thread) could you take a stab at a worksmith suggestion? Was more of a hope 🤷 (also related to another convo from today) Just more of a - Python 2.7 was end of life'd so long ago, but it's still supported. It's fine, I don't think it needs to be called out