Open thejcannon opened 1 year ago
I'm in favour of deprecation, also think it would serve us well to do it as soft as possible. Nice escape is if ./pants
could be used also ~long term as long as there is a Python available for Pants IC.)
Although ./pants
will continue to be useable for old Pants installs, it will not work without modification for pants scies, which will not be distributed through PyPI, but distributed, instead as GitHub releases binaries / manifests. There will be a Pants version, say 2.18.0, that simply requires scie-pants, since it will not release PyPI wheels at all.
So then it just becomes a matter of when
Yes, exactly.
N.B. that with a new clause here: https://github.com/pantsbuild/scie-pants/blob/533d07eb55272e3eabcf449928fbd84c0bc60180/tools/src/scie_pants/configure_pants.py#L118
And a new set of PBS file entries for 3.11 in the lift manifest here: https://github.com/pantsbuild/scie-pants/blob/533d07eb55272e3eabcf449928fbd84c0bc60180/package/scie-pants.lift.json#L7-L84
The existing scie-pants and release process can switch to 3.11. Just pick the Pants cutover version, release scie-pants with that new clause ready to go, then change Pants to only release 3.11 wheels to PyPI at that settled cutover.
With the new
scie-pants
binary, at some point we can "deprecate" the wrapper launcher and start assuming users are using the launcher binary.What this means in practice is that we tighten our interpreter constraints to 1 (recent) version. Which is a boon:
Open question on whether we soft-deprecate (people can still use it if they have the required ICs) or hard-deprecate (truly error if we detect its usage).