#21748 PBS python provider `release_constraints` needs fine-tuning to avoid back-compat risk Issue created by huonw The code itself looks great, but I have two potential bigger-picture things: • The PBS versions Pants has scraped are now explicitly part of the 'public API'. • We currently only record one release tag for each python version, so

release_constraints

are somewhat redundant with

interpreter_constraints

. I think the current

generate_urls.py

script isn't super-careful about how it records assert versions: it looks like it seems to only include the most recent release for each version(?). This may lead to Pants scraping new versions being a breaking change for some users. For instance, it seems all of these releases include 3.12.7: • https://github.com/indygreg/python-build-standalone/releases/tag/20241002 • https://github.com/indygreg/python-build-standalone/releases/tag/20241008 • https://github.com/indygreg/python-build-standalone/releases/tag/20241016 If we had scraped on 2024-10-10, we would record the 20241008 assets only (e.g. asset URLs like `https://github.com/indygreg/python-build-standalone/releases/download/20241008/cpython-3.12.7%2B20241008-aarch64-unknown-linux-gnu-install_only_stripped.tar.gz`). Thus, someone using Pants 2.24 might write

interpreter_constraints == ["==3.12.7"]

,

release_constraints = "==20241008"

(e.g. they identified that 20241002 and 20241016 had bugs). Then, a while later, we re-run the scraping, which picks up 20241016 and thus Pants 2.25 only has those assets (e.g. `https://github.com/indygreg/python-build-standalone/releases/download/20241016/cpython-3.12.7%2B20241016-aarch64-unknown-linux-gnu-install_only_stripped.tar.gz`). The user upgrading from Pants 2.24 to Pants 2.25 will experience breakage because

release_constraints = "==20241008"

will no longer be satisfied: there's no longer 3.12.7 assets with that tag. --- To solve this, I think we can record more assets into `versions_info.json`: every single release for every single version. However, I think this can and should be a follow-up issue and follow-up work building on the groundwork done in this PR: this provider is experimental for a reason! We don't need to get every change perfect before landing. Originally posted by @huonw in #21710 (review) pantsbuild/pants