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.
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/). 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.
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.
>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.)
True. Although if a tool is written in python, it can easily be installed with pip install. I’ve seen so many people get confused by doing pip install poetry in way too many places resulting in a very confusing work environment by having different poetry version and setup depending on which directory you’re in / poetry shell you’ve loaded. If you cannot pip install the tool, this particular madness goes away.
Requests: there’s urllib in the stdlib. It’s requests just worse.
Working with aws means you’re automating things, ci/cd etc. Many people use python they’ve installed locally for months or years without upgrading.
>I’ve seen so many people get confused by doing pip install poetry in way too many places resulting in a very confusing work environment by having different poetry version and setup depending on which directory you’re in / poetry shell you’ve loaded.
This is not actually an error that would have occurred to me to make - since one finds out about Poetry from its webpage, which recommends all sorts of custom installation procedures instead.
That's actually a big part of why I gave up on Poetry: the officially blessed install procedure changed a few times, and it became difficult to uninstall because things installed the old way would expect to be uninstalled the old way as well, but that way was already deprecated. Well, I don't remember the exact details, but it was generally that sort of experience.
(Actually, you gave me some insight for something I should do in the installer I'm designing....)
>Working with aws means you’re automating things, ci/cd etc. Many people use python they’ve installed locally for months or years without upgrading.
Yeah. The download count for boto3 is really absurd, though - something like twice a year per person on Earth (https://pypistats.org/top). I guess that has a fair bit to do with them apparently putting out a patch release every business day.
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.
>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...
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.
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.
