https://github.com/python/prebuilt-cpython # Goals - Produce an archive which contains a build of CPython for all [tier 1 platforms](https://peps.python.org/pep-0011/#tier-1) that can be unpacked anywhere in a file system and simply work - Stretch goal is all [tier 2](https://peps.python.org/pep-0011/#tier-2) platforms ## Non-goals - We are not trying to produce a statically compiled, self-contained binary - That's a lot of security to worry about as we would have to statically compile in a lot # People to talk to Figure out a way to coordinate among various groups that have solve this problem already. This will be important to upstream any patches they have which may help. - [ ] conda (Jannis) - [ ] Anaconda - [ ] [conda-forge](https://github.com/conda-forge/python-feedstock) - [ ] [python-build-standalone](https://github.com/astral-sh/python-build-standalone) (Zanie) - [ ] ActiveState? # Linux - [ ] Can it be done today on `main` as-is? - Probably not as there's bound to be some entries in the resulting ELF binary that need tweaking - [ ] Can it be done using the latest stable [manylinux](https://github.com/pypa/manylinux) image? ## Compatibility At the core dev sprints at Arm, Pablo🍌 was worried about doing a full static build would require we be on top of CVEs for the entire stack (e.g. compilers on up). And so the suggestion was to target [manylinux](https://github.com/pypa/manylinux), but then the question is what glibc version? Do we choose a distro or three to target? But if we do that do we do it based on the latest release or the oldest release that is still under active support? And do we choose based on when CPython 3.\*.0a1 is out (i.e. October), 3.\*.0b1 (i.e. May), 3.\*.0.rc1 (i.e. July), os 3.\*.0 final (i.e. October)? Or do we just go with whatever the manylinux project as selected as stable? https://mayeut.github.io/manylinux-timeline/ shows current manylinux usage. ### Linux distro lifecycle timelines - [Rocky](https://rockylinux.org) [lifecycle](https://wiki.rockylinux.org/rocky/version/) - Active support for 5 years - EOL is 10 years - [Alma](https://almalinux.org) [lifecycle](https://wiki.almalinux.org/release-notes/) - Active support is 5 years - EOL is 10 years - [RHEL](https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux) [lifecycle](https://access.redhat.com/support/policy/updates/errata) - Full support for 5 years - Maintenance for 10 years - Extended add-on for 13 years - [Ubuntu](https://ubuntu.com/download/desktop) [LTS lifecycle](https://ubuntu.com/about/release-cycle) - Standard support is 5 years - Extended support is 10 years - Legacy support is 12 years - [Debian](https://www.debian.org) [support is 5 years](https://www.debian.org/releases/) ### CPU targets What CPU instructions are we going to allow for? ### Compilers Should we use newer compilers than the Linux distro we would be targeting for glibc for better performance (e.g. tail call interpreter requiring clang >=19)? Or is that a compatibility issue? # macOS - [ ] What's the minimum macOS version? - [ ] How is it decided? - [ ] Framework and/or non-framework builds? # Windows Done! 😁