Normally we remove python versions as they become EOL, essentially dropping them just after the stable branch following EOL. python 3.7's formal EOL date is 2023-06-27, which would mean that 2023Q2 would include it, and then it would be removed in July. However, many python packages fail to build with 3.7. Keep in mind that 3.8 and 3.9 are old, 3.10 is the normal stable, 3.11 was released 6 days ago, and surely there is python-current. So 3.7 is viewed as ancient by many people, and almost certainly by almost all people who maintain python modules. While it arguably is a bug for a python package to be released and not support all non-EOL python versions, it's clear that the community of python module projects doesn't see it that way. Right now, there are a lot of bulk build failures with py37-foo, and these obscure the real problems (unrelated to python). That's not ok and we need a solution. To be clear: I view python3.7 as EOL with respect to the community of projects that release python modules. I don't want to struggle against upstreams when it doesn't help me personally. (I'm running 3.10 most places, and 3.9 on one system that I am in the middle of moving from 2022Q2 to 2022Q3.) Possiblities include: 1) Just drop python3.7 right now, because it's clear that the python community views it as effectively EOL. 2) Remove python3.7 from the infrastructure list entirely, but don't delete the package. Thus, no python-using package will have a 37 version, and we'll remove all the 37 lines from packages. python37 will be in pkgsrc, but *no* py37-foo. 3) Change the infrastructure so that unless a package is marked as 37-acceptable, it will be treated as PYTHON_VERSIONS_INCOMPATIBLE+=37. 4) Aggressively add PYTHON_VERSIONS_INCOMPATIBLE+=37 to any package that has bulk build issues and *also* to anything that depends on it, to prevent scan failures. 1 is easy and no risk; we do this every year or so. 2 is easy and fairly low risk. 3 is some work, and it's hard to say how much. Option 4 I fear is a lot of work that will keep biting us when we don't have time to deal. As release manager for 2022Q4 I don't want to do this. Note that if we do option 1, anyone can put python37 in wip and use it locally if they want. That's pretty close to option 2, except python37 won't be in binary package sets. So: Does anyone actually use python37 from pkgsrc (who is running pkgsrc-current, or who is running 2022Q3 and who regularly updates to new quarterly releases)*? Please speak up and explain why. (Or send me text to post anonymously if you don't want to admit it public.) Can anyone explain the harm that would result if pkgsrc outright removes python37 (option 1)? I don't mean "would be nice if we kept it", I mean articulating an actual bad result. Can anyone explain how they would benefit from option 2 instead of 1? Does anybody want to volunteer to implement and test the changes for 3, in time for branch stability rules? A change, and a bulk build with them, done by 11/15? Or opine on the total time that it would take pkgsrc committers to do this and undo it, vs the total time saved by people that would use it? (My bias is pretty clear here!) * If you aren't up-to-date with pkgsrc, what we change in the future doesn't affect you, and I don't want to impose work on the small set of people who fix things to accomodate theoretical people who might update but haven't been. Unless there are good reasons not to delete python37 received by 10Z on 6 November, I will tell the people that want to remove python37 to go ahead (option 1). Thanks, Greg
Attachment:
signature.asc
Description: PGP signature