https://pantsbuild.org/ logo
Join Slack
Powered by
Is there any history to the choice of subsystem `d...
# development
w
Is there any history to the choice of subsystem 
default_requirements
? For example, here's pylint's, which gives us a default pylint from Sept 2023. 
default_requirements = ["pylint>=2.13.0,<3"]
I'm guessing we have broad ranges (rather than specific versions) to let a broader set of Pythons work out of the box?
To support 3.14, we need to bump some subsystems, which also means dropping older interpreters - unless we want to do some conditional, convoluted stuff. In my case, i had to drop 3.9 on pylint - but turns out it was end of lifed a couple days ago https://devguide.python.org/versions/#unsupported-versions
h
We wouldn't be dropping older interpreters completely, we'd only be doing so in the default requirements. Folks can still work with older interpreters if they set up their own lockfiles for the tools.
See https://github.com/pantsbuild/pants/pull/22578 for an example of such an update
w
Yeah, for sure - hence the “default”. I guess more precisely, I should ask, what’s the guiding star(s) for setting those constraints? They’re slightly different from backend to backend and specific case to specific case. I think some are pinned, while others are wide constraints. Using that PR you have, I feel like the sentiment could be generalized to: ”Widest set of default requirements that that captures our widest set of interpreters, conditional to Pants repo tests passing“? Example: If we can support “>=3.9,<4”, then we can open up those default_requirements as wide as possible. However, in the 
pylint
example, the version that supports 3.14 drops support for 3.9 - so, would it be fair to register default_constraints of “>=3.10,<4” for that subsystem and apply the narrower set of pylint constraints? Or, should we have multiple sets of interpreter constraints + requirements constraints? This is relevant for the 3.14 branch, but also I’m trying to capture as much tribal knowledge as possible into the docs
c
Python 3.9 just went EOL on 2025-10-31, so I think is fine to drop from the default lockfiles
w
I agree, but we currently keep a lot of 3.8 still (including running tests on it) but it was EOL in 2024
h
Yes, I think it's fine. And that PR above dropped 3.8 more or less.
w
Did it? I saw a couple 3.8isms while doing the 3.14 branch. If there is no opposition, I can go 3.10 to 3.14, and remove the 3.8/3.9 custom testing in the repo?
Actually, the tests are a bit weird, because we're not dropping support per se - we're dropping defaults. But someone can setup their own lockfiles with 3.8 or 3.9 - so, we'd still need to maintain them in the lockfiles to run associated tests
p
As wide as possible within reason. Increase the default interpreter constraints without removing the tests that maintain backwards compatibility support. I still have projects that (sadly) use Python 3.8. So, I hope we don't break support for that any time soon. (No issues with removing from default interpreter constraints.)
w
Right, but we'll still want those to run - I haven't checked the tests recently to see if we use different constraints within them when using those python version macros. I'm fine keeping them, just sad we can't speed up CI by doing less 😢
I just don't want silently skipped tests e.g.
Copy code
@pytest.mark.platform_specific_behavior
@pytest.mark.parametrize(
    "major_minor_interpreter",
    all_major_minor_python_versions(["CPython>=3.9,<4"]),
)
p
Hmm. Can we use coverage to track which tests are not running in CI? Some kind of meta-check that looks at tests across all platforms to warn (or error) when a test is no longer running in CI?
w
Good question - to be clear, some of this might already be covered. I'm just not sure myself, as I haven't checked it. Still dealing with deprecations first
9 Views
Open in Slack
PreviousNext
Powered by