For now most people would do well to stick to python.org installers for mac and windows.

For linux, official repos are ideal. If you really, really can't (which is different than wanting to), ubuntu deadsnake and red hat epl are the best second plan, while already more finicky.

If you use something more exotic, you chose hardship, and you will have to be up to the task.

Anything else will come with bigger caveats than the people promoting them will really admit to.

The story is of course a bit richer because linux packaging is fun, so I'll complete with:

https://www.bitecode.dev/p/installing-python-the-bare-minimu...

Thete are currently no silver bullet to bootstrap python on linux. I tried all of them with hundred of colleagues and trainees.

I do have hope for astral to come up with one but don't run on rye thinking your life is saved.

Even on Macs, you can use MacPorts. They provide a lot of versions pre-compiled (and everything is BSD-solid).

I know you mean well, but such advice is why so many beginners have painful Python experience.

Macports and homebrew Pythons are dependencies of other packages. They can be used by you, but they are not meant for you.

This means at some point, they will contain a surprise, and not a good one.

> but such advice is why so many beginners have painful Python experience

Sample of one, but I never encountered anything even broken in MacPorts. They seem to embrace the BSD ethos of doing everything right (even if at a slower pace, as some packages lag a few releases behind Homebrew).

Personally I only use MacPorts or Homebrew to install random smaller tools. It's easier to install Python, NodeJS, Postgres, etc binaries from the main website.

These builds are an alternative: https://github.com/indygreg/python-build-standalone

Those are what Rye and hatch use.

Drawbacks: late availability of patch versions, various quirks from how they are built (missing readline, missing some build info that self-compiled C python modules might need.)

I think PEP711 (https://peps.python.org/pep-0711/) is (eventually) a better alternative, because it builds on top of the proven manylinux approach to binary compatibility.

Those are proof of concept builds now and will eventually hopefully replace indygreg's builds.

Not only does the format need to exist but the service of building and publishing them is needed too.

Very cool, this is the first time I'm hearing of PEP 711! I hope this (or some other PEP like it) will get accepted eventually!

I hope this will be merged with indygreg builds at some point, but the community move slowly on those issues so it may take years.

> Every solution that I know of on Linux requires you to build Python on the machine

Unless you need a Python that's not supported by your Linux distribution, you can just use what's available.

On macOS, MacPorts provides compiled versions for 3.2 all the way to 3.13, as well as 2.6 and 2.7. Right now, I have 3.8, 3.9, 3.10, 3.11, 3.12, and a 3.13 development build. The fact it's not Linux (or x86) might cause some frustration.

If you’re lucky enough to be on a Linux system that uses apt some thankless soul maintains a repo called deadsnakes with all these binaries. Fabulous if you’re using any somewhat old version of Python in CI for instance. Yum based systems are SOL as far as I can tell. Build and host your own binary for that. Apk doesn’t have this either IIRC

If you are deploying to such an ancient OS, it's perhaps easier to have the whole OS packaged as a container or a VM and use that. It's not only different Python versions that might bite you.

What makes you think that GP’s comment is talking about older OSes?

My understanding of their comment is that they’re talking about getting older Python interpreters to run on more modern OSes, modern enough that they don’t carry the older Python as a system package anymore. Hence, deadsnakes.

This is not about system packages or OSes, this is about your application needing Python 3.9.7 specifically, and locking to that, and 3.9.7 not being available in repositories anymore (3.9.7 is just an example). So normally you would either need to self host 3.9.7 somewhere or compile it from source on every new machine (which is terrible for CI but fine for local dev, a one off in local dev to build a Python version is nothing but paying 4 minutes every time on ci to compile your version of Python from source is a very angry amount of time for a lot of people).

> needing Python 3.9.7 specifically

That's indeed extremely specific. I'd imagine this pain could be self-inflicted with C-based extensions that were compiled (and can't be recompiled) with structures that don't exist in other versions.

I don't want to imagine what other eldritch horrors await developers working on this application.

Usually it is not the patch version being important eg being specifically 3.9.7, but rather picking one supported version and pinning it. Yes we should all be on the latest Python version that is available in the mainline repos and distros as a binary but a lot of orgs I’ve seen don’t invest the time and effort to properly be upgrading to be on the latest version of deps. So you are usually having one specific supported Python version that everyone builds against which may or may not be new enough to be in the official repo.

I also imagine the scenario you mentioned causing a lock to a patch version. But I see this as just a normal steady state a lot of orgs drift to if not staying on top of version updates

The thankless soul is the awesome Anthony Sottile, who is also the author of pre-commit.ci: https://twitter.com/codewithanthony

Drop by and send thanks cause he really needs them.

deadsnakes is useful, but also a bit of a misnomer. One can use it to get pretty much anything python version, even ones that are too new to be available in your default apt repos. That is, it's not just for 'dead'/EOL versions.

That's exactly why I don't really on that for Ubuntu though. It's a single point of failure, when I can just use `asdf` to install Python and easily switch between it, automatically if setup correctly on projects.

I use asdf on my local machine, stuff like deadsnakes is for when you need your CI to use VaguelyOldButStillSupported Python version and don’t want to either compile Python from source or host your own binary

My use case is that I'm almost always using the latest Python version, which many Linux distros don't have in their packaging yet, and I'm upgrading code using old versions to the latest. asdf is the best tool for that.

Rye downloads pre-built binaries.

I'll leave further discussion of the reliability and provenance of said binaries to someone else.

Binaries are quite reliable and from a serious project, but rye is young and uses shim.

Still, it's part of those new generation of tooling that bringing hope for the next few years.

> What is the alternative?

Using per-distro official installation channels.

E.g. using deadsnakes PPA on Ubuntu, AUR on Arch Linux, etc.

try pyoxidizer