5 ms·

> it compiles python on your machine What is the alternative? Every solution that I know of on Linux requires you to build Python on the machine: asdf, officia

by bmitc 3y ago

> it compiles python on your machine What is the alternative? Every solution that I know of on Linux requires you to build Python on the machine: asdf, official Python downloads, etc.

bheadmaster 3y ago
> What is the alternative? Using per-distro official installation channels. E.g. using deadsnakes PPA on Ubuntu, AUR on Arch Linux, etc.
Leynos 3y ago
Rye downloads pre-built binaries. I'll leave further discussion of the reliability and provenance of said binaries to someone else.
- BiteCode_dev 3y ago
  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.
kzrdude 3y ago
These builds are an alternative: https://github.com/indygreg/python-build-standalone 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.)
- formerly_proven 3y ago
  I think PEP711 (https://peps.python.org/pep-0711/ https://peps.python.org/pep-0711/) is (eventually) a better alternative, because it builds on top of the proven manylinux approach to binary compatibility.
  - kzrdude 3y ago
    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.
  - codethief 3y ago
    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!
  - BiteCode_dev 3y ago
    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.
BiteCode_dev 3y ago
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-minimum 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.
- rbanffy 3y ago
  Even on Macs, you can use MacPorts. They provide a lot of versions pre-compiled (and everything is BSD-solid).
  - BiteCode_dev 3y ago
    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.
    - rbanffy 3y ago
      > 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).
  - hot_gril 3y ago
    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.
rbanffy 3y ago
> 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.
- SOLAR_FIELDS 3y ago
  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
  - rbanffy 3y ago
    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.
    - Hackbraten 3y ago
      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.
      - SOLAR_FIELDS 3y ago
        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).
tgz 3y ago
try pyoxidizer

by bmitc 3y ago

> it compiles python on your machine What is the alternative? Every solution that I know of on Linux requires you to build Python on the machine: asdf, official Python downloads, etc.

bheadmaster 3y ago

> What is the alternative? Using per-distro official installation channels. E.g. using deadsnakes PPA on Ubuntu, AUR on Arch Linux, etc.

Leynos 3y ago

Rye downloads pre-built binaries. I'll leave further discussion of the reliability and provenance of said binaries to someone else.

BiteCode_dev 3y ago
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.

kzrdude 3y ago

These builds are an alternative: https://github.com/indygreg/python-build-standalone 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.)

formerly_proven 3y ago
I think PEP711 (https://peps.python.org/pep-0711/ https://peps.python.org/pep-0711/) is (eventually) a better alternative, because it builds on top of the proven manylinux approach to binary compatibility.
- kzrdude 3y ago
  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.
- codethief 3y ago
  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!
- BiteCode_dev 3y ago
  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.

BiteCode_dev 3y ago

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-minimum 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.

rbanffy 3y ago
Even on Macs, you can use MacPorts. They provide a lot of versions pre-compiled (and everything is BSD-solid).
- BiteCode_dev 3y ago
  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.
  - rbanffy 3y ago
    > 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).
- hot_gril 3y ago
  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.

rbanffy 3y ago

> 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.

SOLAR_FIELDS 3y ago
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
- rbanffy 3y ago
  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.
  - Hackbraten 3y ago
    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.
    - SOLAR_FIELDS 3y ago
      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).

tgz 3y ago

try pyoxidizer