3 ms·

I’ve been missing a python tool like this that isn’t written in python. Conda was good in this regard - having a distribution without first installing python is

I’ve been missing a python tool like this that isn’t written in python. Conda was good in this regard - having a distribution without first installing python is a massive improvement to the «getting started» problems in python.

rollcat 2y ago
Welcome to the bootstrapping problem. The original take is "how do I build a C compiler without a C compiler", and some amazingly gifted people from the GNU/Guix team managed to take it to its logical conclusion - and wrote a 357 byte piece of annotated machine code, from which an entire distro can be bootstrapped. On the bright side, uv is written in Rust, which makes distributing prebuilt releases practical, and helps end-users getting started. OTOH Linux+GNU+GCC pale in comparison to Rust's own bootstrapping problem - each Rust compiler is written in some previous release/dialect of Rust, all the way back to the pre-1.0 days, when it was written in an obscure dialect of OCaml. There are efforts underway to make Rust bootstrappable, but as of right now the Python ecosystem might be painting itself into a corner with slowly making Rust a hard dependency. https://bootstrappable.org https://bootstrappable.org
- wakawaka28 2y ago
  >On the bright side, uv is written in Rust, which makes distributing prebuilt releases practical, and helps end-users getting started. OTOH Linux+GNU+GCC pale in comparison to Rust's own bootstrapping problem - each Rust compiler is written in some previous release/dialect of Rust, all the way back to the pre-1.0 days, when it was written in an obscure dialect of OCaml. There are efforts underway to make Rust bootstrappable, but as of right now the Python ecosystem might be painting itself into a corner with slowly making Rust a hard dependency. Thankfully the Python ecosystem probably isn't going to adopt this crazy Rust dependency. The Rust nuts are unbelievably and laughably persistent but this is an overcomplicated solution that nobody asked for. You could probably say the same about Rust in the Linux kernel so who knows...
  - rollcat 2y ago
    Rust-the-language is fine. Rust-the-blessed-toolchain is the problem. In practical terms, it delivers enormous value, it's about the problems that lay down the road. Once Rust can be easily bootstrapped? Like you can build the official Go toolchain from 1.4? I'd argue Rust in Linux is less of a problem than Linux itself growing out of bounds. Compare seccomp with OpenBSD's pledge/unveil. But there's a reason why Linux is winning by a margin of 100.000x: it's simply more practical, even if less simple.
    - wakawaka28 2y ago
      I don't think Rust delivers this tremendous value. Bootstrapping it doesn't do much unless everything gets migrated forward to the bootstrappable version. It's got all the worst aspects of a systems language combined with all the pain points of npm. I don't want to be required to be online or to download hundreds of unvetted bullshit packages to make a simple program, and that's the way it's made.
zahlman 2y ago
I've really never understood this objection. Users that need multiple actual versions of Python (as opposed to separate venvs) are usually more technically sophisticated; Python for Windows comes as an installer and Linux is generally dependent on it already (and a usable dev environment is only `python -m venv` away). But more to the point, writing an application in another language - or at all - isn't relevant to solving that problem. There's no reason you couldn't have a downloadable freestanding Pip package that comes with its own Python - just have the user unpack a zip archive or whatever, and have all the needed files in the right place. That just doesn't happen because it seems backwards. There's been an initiative to standardize portable Python binaries that would facilitate that sort of approach (and make them installable from PyPI), called PyBI (https://peps.python.org/pep-0711/ https://peps.python.org/pep-0711/). Yes, you still have to do that installation. But at least in principle, you don't need an installer for it; you could download from the PyPI website and unzip the wheel.
- pletnes 2y ago
  You’re mostly correct. However in practice this has failed to materialize. The issue which I think confuses people is the conflation between the python environment of the packaging tool and the environment you should use for your code. Even anaconda python used to make this mistake, if I recall correctly.
  - zahlman 2y ago
    >The issue which I think confuses people is the conflation between the python environment of the packaging tool and the environment you should use for your code. This is primarily Pip's fault, because it spent many years championing a model where it would be copied into each new "environment you should use for your code". Most of the benefits people attribute to Python tools because they're "written in a language other than Python", are really just benefits owing to the tool being isolated from the dev environment. And for about the last two years, this has been reasonable with Pip (possible but unreasonably complicated before; now it uses a weird hack, but the experience is pretty smooth). People just don't know about it, in part because they aren't forcefully confronted with it (because copying Pip is still the default for the `venv` standard library module). It's noteworthy that the standard library does contain `venv` - but not more complex things; technically not even Pip. This rhymes strongly with the philosophy that designed the rest of the standard library. It's the same reason we don't have Requests in there, or, say, `python-dateutil`. (Actually, boto3 gets more than twice as many downloads as Requests, but it's hard to understand why. Working with AWS is surely far more niche than making HTTP connections.)

rollcat 2y ago

Welcome to the bootstrapping problem. The original take is "how do I build a C compiler without a C compiler", and some amazingly gifted people from the GNU/Guix team managed to take it to its logical conclusion - and wrote a 357 byte piece of annotated machine code, from which an entire distro can be bootstrapped. On the bright side, uv is written in Rust, which makes distributing prebuilt releases practical, and helps end-users getting started. OTOH Linux+GNU+GCC pale in comparison to Rust's own bootstrapping problem - each Rust compiler is written in some previous release/dialect of Rust, all the way back to the pre-1.0 days, when it was written in an obscure dialect of OCaml. There are efforts underway to make Rust bootstrappable, but as of right now the Python ecosystem might be painting itself into a corner with slowly making Rust a hard dependency. https://bootstrappable.org https://bootstrappable.org

wakawaka28 2y ago
>On the bright side, uv is written in Rust, which makes distributing prebuilt releases practical, and helps end-users getting started. OTOH Linux+GNU+GCC pale in comparison to Rust's own bootstrapping problem - each Rust compiler is written in some previous release/dialect of Rust, all the way back to the pre-1.0 days, when it was written in an obscure dialect of OCaml. There are efforts underway to make Rust bootstrappable, but as of right now the Python ecosystem might be painting itself into a corner with slowly making Rust a hard dependency. Thankfully the Python ecosystem probably isn't going to adopt this crazy Rust dependency. The Rust nuts are unbelievably and laughably persistent but this is an overcomplicated solution that nobody asked for. You could probably say the same about Rust in the Linux kernel so who knows...
- rollcat 2y ago
  Rust-the-language is fine. Rust-the-blessed-toolchain is the problem. In practical terms, it delivers enormous value, it's about the problems that lay down the road. Once Rust can be easily bootstrapped? Like you can build the official Go toolchain from 1.4? I'd argue Rust in Linux is less of a problem than Linux itself growing out of bounds. Compare seccomp with OpenBSD's pledge/unveil. But there's a reason why Linux is winning by a margin of 100.000x: it's simply more practical, even if less simple.
  - wakawaka28 2y ago
    I don't think Rust delivers this tremendous value. Bootstrapping it doesn't do much unless everything gets migrated forward to the bootstrappable version. It's got all the worst aspects of a systems language combined with all the pain points of npm. I don't want to be required to be online or to download hundreds of unvetted bullshit packages to make a simple program, and that's the way it's made.

zahlman 2y ago

I've really never understood this objection. Users that need multiple actual versions of Python (as opposed to separate venvs) are usually more technically sophisticated; Python for Windows comes as an installer and Linux is generally dependent on it already (and a usable dev environment is only `python -m venv` away). But more to the point, writing an application in another language - or at all - isn't relevant to solving that problem. There's no reason you couldn't have a downloadable freestanding Pip package that comes with its own Python - just have the user unpack a zip archive or whatever, and have all the needed files in the right place. That just doesn't happen because it seems backwards. There's been an initiative to standardize portable Python binaries that would facilitate that sort of approach (and make them installable from PyPI), called PyBI (https://peps.python.org/pep-0711/ https://peps.python.org/pep-0711/). Yes, you still have to do that installation. But at least in principle, you don't need an installer for it; you could download from the PyPI website and unzip the wheel.

pletnes 2y ago
You’re mostly correct. However in practice this has failed to materialize. The issue which I think confuses people is the conflation between the python environment of the packaging tool and the environment you should use for your code. Even anaconda python used to make this mistake, if I recall correctly.
- zahlman 2y ago
  >The issue which I think confuses people is the conflation between the python environment of the packaging tool and the environment you should use for your code. This is primarily Pip's fault, because it spent many years championing a model where it would be copied into each new "environment you should use for your code". Most of the benefits people attribute to Python tools because they're "written in a language other than Python", are really just benefits owing to the tool being isolated from the dev environment. And for about the last two years, this has been reasonable with Pip (possible but unreasonably complicated before; now it uses a weird hack, but the experience is pretty smooth). People just don't know about it, in part because they aren't forcefully confronted with it (because copying Pip is still the default for the `venv` standard library module). It's noteworthy that the standard library does contain `venv` - but not more complex things; technically not even Pip. This rhymes strongly with the philosophy that designed the rest of the standard library. It's the same reason we don't have Requests in there, or, say, `python-dateutil`. (Actually, boto3 gets more than twice as many downloads as Requests, but it's hard to understand why. Working with AWS is surely far more niche than making HTTP connections.)