941–950 of 1001 posts
Earlier quoted context omitted.
This isn't a comment just about Python.. but it should just work. There shouldn't be constant ceremony for getting and keeping environments running.
It does, Python has essentially solved it for years.
The pieces actually all existed for sure.
I can even write scripts to make it all happen.
But uv remains as a long overdue universal command line tool for python.
Honestly though it's a pretty rough indictment of Python that the best thing to happen in a decade is that people started writing Python tools in Rust. Not even a little Rust, uv is 98% Rust. I mean, they just released 3.14 and that was supposed to be a pretty big deal.
I sometimes wonder if many core Python people don’t actually like the language that much. That’s why (a) they’re constantly reinventing it, and (b) they celebrate rewrites from Python into other languages. Long before Rust, it was considered a good thing when a standard library module was rewritten in C. Compare this to the Go community, who celebrate rewrites from other languages into Go. They rewrote their compiler…
Python is an interpreted scripting language that was not originally designed with high performance computing in mind. It's perfectly normal for languages like that to have their tooling written in a systems programming language. It's also perfectly normal for languages like that to have components that do need to be performant written in a systems programming language. We call this, "Using the right tool for the job."
It's true that a lot of historical Python toolchain was written in Python. That was also using the right tool for the job. It's a holdover from a time when Python was still mostly just a scripting language, so projects were smaller and packages were smaller and dependency trees were smaller and there just generally weren't as many demands placed on the toolchain.
Go, by contrast, is itself a systems programming language. And so naturally they'd want to have all the systems components written in Go, and the sooner the better. It wouldn't inspire much confidence if the maintainers of a systems programming language didn't trust it with systems programming tasks.
Honestly though it's a pretty rough indictment of Python that the best thing to happen in a decade is that people started writing Python tools in Rust. Not even a little Rust, uv is 98% Rust. I mean, they just released 3.14 and that was supposed to be a pretty big deal.
I sometimes wonder if many core Python people don’t actually like the language that much. That’s why (a) they’re constantly reinventing it, and (b) they celebrate rewrites from Python into other languages. Long before Rust, it was considered a good thing when a standard library module was rewritten in C. Compare this to the Go community, who celebrate rewrites from other languages into Go. They rewrote their compiler…
I wouldn't describe having a culture that isn’t exclusivisy fanaticism as not liking the language, though.
Earlier quoted context omitted.
I use this but I hate it. I want to be able to ship a bundle which needs zero network access to run, but will run. It is still frustratingly difficult to make portable Python programs.
Zipapp comes close: https://docs.python.org/3/library/zipapp.html
Earlier quoted context omitted.
We've all done it. I'm curious though, I wonder what would be the best way to prevent a user from doing this.
Wrap curl to detect if /dev/stdout is a pipe and if the output is a script - this is fast because of the hash-bang. From there you can do a lot of fancy things: replace the output with echo "don't do this" ; exit 1", check the Url against a list of well known accepted scripts based on hash, run the unknown ones through an LLM to validate if they are potentially malicious, etc.
Run my command through an LLM and tell me "don't do this" once, I'm out to a different distro :-).
Also, if people copy-paste stuff they don't understand in a terminal (and running a script like this is pretty much "running stuff one does not understand"), I don't think there is anything you can do for them.
Should I try this? I, let’s say, code with Ai and am not an engineer. Python related environment stuff makes my head explode (across the 3 computers I use). It’s the main thing my brain just can’t seem to figure out.
I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing
The sticking point for me is the way tools like uv and poetry build everything around the idea of a "project". I don't want a separate environment for every project, and I don't want to start by creating a project. I want to start with an environment that has stuff in it, and I start fiddling around, and gradually something comes together that eventually will be pulled out into a separate project. From what I can see…
This is me exactly. I have a default dev environment, and a couple for experimenting with new versions of various packages, I don't need or want "projects" most of the time
uv.lock is a bless