I've replaced the linkbait title with an attempt at saying what the feature is. If there's a more accurate wording, we can change it again.
uh, thanks I guess.
It's just standard practice here. See https://news.ycombinator.com/newsguidelines.html.
Uv's killer feature is making ad-hoc environments easy
91–100 of 428 posts
Re: Uv's killer feature is making ad-hoc environments easy
#92As a NodeJS developer it's still kind of shocking to me that Python still hasn't resolved this mess. Node isn't perfect, and dealing with different versions of Node is annoying, but at least there's none of this "worry about modifying global environment" stuff.
Caveat: I'm a node outsider, only forced to interact with it But there are a shocking number of install instructions that offer $(npm i -g) and if one is using Homebrew or nvm or a similar "user writable" node distribution, it won't prompt for sudo password and will cheerfully mangle the "origin" node_modules So, it's the same story as with python: yes, but only if the user is disciplined Now ruby drives me fucking b…
Ruby has a number of solutions for this - rvm (the oldest, but less popular these days), rbenv (probably the most popular), chruby/gem_home (lightweight) or asdf (my personal choice as I can use the same tool for lots of languages). All of those tools install to locations that shouldn't need root.
Re: Uv's killer feature is making ad-hoc environments easy
#93As a NodeJS developer it's still kind of shocking to me that Python still hasn't resolved this mess. Node isn't perfect, and dealing with different versions of Node is annoying, but at least there's none of this "worry about modifying global environment" stuff.
Python has been cleaning up a number of really lethal problems like: (i) wrongly configured character encodings (suppose you incorporated somebody else's library that does a "print" and the input data contains some invalid characters that wind up getting printed; that "print" could crash a model trainer script that runs for three days if error handling is set wrong and you couldn't change it when the script was runni…
I don’t exactly remember the situation but a user created a python module named error.py.
Then in their main code they imported the said error.py but unfortunately numpy library also has an error.py. So the user was getting very funky behavior.
Re: Uv's killer feature is making ad-hoc environments easy
#94Earlier quoted context omitted.
pip's resolving algorithm is not sound. If your Python projects are really simple it seems to work but as your projects get more complex the failure rate creeps up over time. You might pip install something and have it fail and then go back to zero and restart and have it work but at some point that will fail. conda has a correct resolving algorithm but the packages are out of date and add about as many quality probl…
May I introduce you to our lord and saviour, Nix and it's most holy child nixpkgs! With only a small tithing of your sanity and ability to Interop with any other dependency management you can free yourself of all dependency woes forever ! [ ] For various broad* definitions of forever. [*] Like, really, really broad** [**] Maybe a week if you're lucky
Except python builders in nixpkgs are really brain damaged because of the writers ways they inject search path which for example breaks if you try to execute a separate python interpreter assuming same library environment...
Re: Uv's killer feature is making ad-hoc environments easy
#95Earlier quoted context omitted.
I never used anything other than pip. I never felt the need to use anything other than pip (with virtualenv). Am I missing anything?
Much of the Python ecosystem blatantly violates semantic versioning. Most new tooling is designed to work around the bugs introduced by this.
To be fair, Python itself doesn’t follow SemVer.
Not in a “they break things they shouldn’t,” but in a “they never claim to be using SemVer.”
Re: Uv's killer feature is making ad-hoc environments easy
#96Heck, you can get even cleaner than that by using uv’s support for PEP 723’s inline script dependencies: # /// script # requires-python = ">=3.12" # dependencies = [ # "pandas", # ] # /// h/t https://simonwillison.net/2024/Dec/19/one-shot-python-tools/
I don't understand how things like this get approved into PEPs.
Re: Uv's killer feature is making ad-hoc environments easy
#97Earlier quoted context omitted.
Python has been cleaning up a number of really lethal problems like: (i) wrongly configured character encodings (suppose you incorporated somebody else's library that does a "print" and the input data contains some invalid characters that wind up getting printed; that "print" could crash a model trainer script that runs for three days if error handling is set wrong and you couldn't change it when the script was runni…
I don’t exactly remember the situation but a user created a python module named error.py. Then in their main code they imported the said error.py but unfortunately numpy library also has an error.py. So the user was getting very funky behavior.
... it's tricky. In Java there's a cultural expectation that you name a package like
package organization.dns.name.this.and.that;
package this.and.that;
package their.this.and.that;
Re: Uv's killer feature is making ad-hoc environments easy
#98As a NodeJS developer it's still kind of shocking to me that Python still hasn't resolved this mess. Node isn't perfect, and dealing with different versions of Node is annoying, but at least there's none of this "worry about modifying global environment" stuff.
Because node.js isn't a dependency of the Operating system. Also we don't have a left pad scale dependency ecosystem that makes version conflicts such a pressing issue.
This. IME, JS devs rarely have much experience with an OS, let alone Linux, and forget that Python literally runs parts of the OS. You can’t just break it, because people might have critical scripts that depend on the current behavior.
Re: Uv's killer feature is making ad-hoc environments easy
#99Heck, you can get even cleaner than that by using uv’s support for PEP 723’s inline script dependencies: # /// script # requires-python = ">=3.12" # dependencies = [ # "pandas", # ] # /// h/t https://simonwillison.net/2024/Dec/19/one-shot-python-tools/
I don't understand how things like this get approved into PEPs.
As in, you think this shouldn't be possible or you think it should be written differently?
Re: Uv's killer feature is making ad-hoc environments easy
#100Earlier quoted context omitted.
Pip only has requirements.txt and doesn't have lockfiles, so you can't guarantee that the bugs you're seeing on your system are the same as the bugs on your production system.
The requirements.txt file is the lockfile. Anyways, this whole obsession with locked deps or "lockfiles" is such an anti-pattern, I have no idea why we went there as an industry. Probably as a result of some of the newer stuff that is classified as "hipster-tech" such as docker and javascript.
Just because you don't understand it, it's ok to call it an "anti-pattern"?
Reproducibility is important in many contexts, especially CI, which is why in Node.js world you literally do "npm ci" that installs exact versions for you.
If you haven't found it necessary, it's because you haven't run into situations where not doing this causes trouble, like a lot of trouble.