search

indygreg / python-build-standalone

Produce redistributable builds of Python
Mozilla Public License 2.0
2.13k stars 133 forks source link

Remove support for Python 3.8 #342

Closed zanieb closed 3 weeks ago

zanieb commented 1 month ago

I'll fill in some details here, but we should probably simplify the builds by dropping support for 3.8 now that it is EOL. I'm not sure how long we want to support versions after they're EOL, but the build matrix is huge as-is.

indygreg commented 1 month ago

I've historically dropped support (read: stopped publishing and deleted code to build) Python versions once they hit EOL per upstream.

So it is time to remove 3.8 from PBS.

jbvsmo commented 1 month ago

I was on a similar discussion on uv project and it does seems to me that astral and indygreg might have different goals when creating these compiled versions of python.

IMO Astral wants to build a widely adopted toolchain that can install python in as many systems as possible for end users and indygreg wants to have every single variation of a target triplet available for the most recently supported python for modern systems, not necessarily for end users only.

There is a huge overlap, but I see things that does not benefit uv directly here and things that uv would benefit from being dropped. E.g.

Benefit direct users of python-build-standalone but does not benefit uv users:

Benefits uv users but does not benefit direct users of python-build-standalone :

The point @zanieb made was that linux build matrix was too complex and took too many hours.

So, I have a few suggestions:

  1. Have separated workflows for each version of Python to guarantee they can be triggered independently.
  2. Make slim and wide releases where slim means only optimized builds for platforms supported by uv.

I would suggest that uv have a fork of this project on the Astral org where they can run the slim version of the workflow for more python versions (e.g. 3.7-3.14) and indygreg can continue running the wide version but for fewer python versions (e.g. 3.9-3.13).

That way you can have a single code base by keeping the forks in sync but each triggering the release mechanism with different parameters.

So what this means for this issue?

Don't drop the python 3.8 code, please

zanieb commented 1 month ago

As I mentioned in the linked discussion, I don't think that separating the builds helps; we need to continuously test to ensure we're not breaking things. Only running 3.8 builds in a fork means we'd end up doing more work to incorporate upstream changes — I don't think that's a great outcome.

As a side note, I plan on adding support for debug builds in uv and I think there's been a request for x86_64 variant support. Those builds aren't useless for uv users.