Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uv's killer feature is making ad-hoc environments easy

valatka.dev

Post reply on HN
Print view View original

331–340 of 428 posts

Re: Uv's killer feature is making ad-hoc environments easy

#331

Post by zahlman »

matsemann wrote: post #275
zahlman wrote: post #242

Earlier quoted context omitted.

>Respectively, yes. The ability to create venvs so fast, that it becomes a silent operation that the end user never thinks about anymore. I might just blow your mind here: $ time python -m venv with-pip real 0m3.248s user 0m3.016s sys 0m0.219s $ time python -m venv --without-pip without-pip real 0m0.054s user 0m0.046s sys 0m0.009s The thing that actually takes time is installing Pip into the venv. I already have loca…

It's not the "runtime" that's slow for me with pip, but all the steps needed. My biggest gripe with python is you need to basically be an expert in different tools to get a random project running. Uv solves this. Just uv run the script and it works. I don't care if pip technically can do something. The fact that I explicitly have to mess around with venvs and the stuff is already enough mental overhead that I disrega…

None of GP is about what Pip can technically do. It's about what a better tool still written in Python could do.

The problems you're describing, or seeing solved with uv, don't seem to be about a problem with the design of virtual environments. (Uv still uses them.) They're about not having the paradigm of making a venv transiently, as part of the code invocation; or they're about not having a built-in automation of a common sequence of steps. But you can do that just as well with a couple lines of Bash.

I'm not writing any of this to praise the standard tooling. I'm doing it because the criticisms I see most commonly are inaccurate. In particular, I'm doing it to push back against the idea that a non-Python language is required to make functional Python tooling. There isn't a good conceptual reason for that.

Re: Uv's killer feature is making ad-hoc environments easy

#332

Post by zahlman »

IanCal wrote: post #322
zahlman wrote: post #221

Earlier quoted context omitted.

> pip doesn't resolve dependencies of dependencies. This is simply incorrect. In fact the reason it gets stuck on resolution sometimes is exactly because it resolved transitive dependencies and found that they were mutually incompatible. Here's an example which will also help illustrate the rest of my reply. I make a venv for Python 3.8, and set up a new project with a deliberately poorly-thought-out pyproject.toml:…

> This is simply incorrect. In fact the reason it gets stuck on resolution sometimes is exactly because it resolved transitive dependencies and found that they were mutually incompatible. The confusion might be that this used to be a problem with pip. It looks like this changed around 2020, but before then pip would happily install broken versions. Looking it up, this change of resolution happened in a minor release.

You have it exactly, except that Pip 20.3 isn't a "minor release" - since mid-2018, Pip has used quarterly calver, so that's just "the last release made in 2020". (I think there was some attempt at resolving package versions before that, it just didn't work adequately.)

Re: Uv's killer feature is making ad-hoc environments easy

#333

Post by TeMPOraL »

mixmastamyk wrote: post #260
athrun wrote: post #163

Earlier quoted context omitted.

> sudo apt-get install python3.10 python3.11 python3.12 This assumes the Python version you need is available from your package manager's repo. This won't work if you want a Python version either newer or older than what is available. > You are incorrect about needing to use an additional tool to install a "global" tool like `ruff`; `pip` does this by default when you're not using a virtual environment. True, but it'…

>> You are incorrect about needing to use an additional tool to install a "global" tool like `ruff`; `pip` does this by default when you're not using a virtual environment. >True, but it's not best practice to do that because while the tool gets installed globally, it is not necessarily linked to a specific python version, and so it's extremely brittle. "Globally" means installed with sudo. These are installed into t…

> "Globally" means installed with sudo. These are installed into the user folder under ~/.local/ and called a user install by pip.

> It works fine until you upgrade to a new version of python, in which case you install the package again.

Debian/Ubuntu doesn't want you to do either, and tell you you'll break your system if you force it (the override flag is literally named "--break-system-packages"). Hell, if you're doing it with `sudo`, they're probably right - messing with the default Python installation (such as trying to upgrade it) is the quickest way to brick your Debian/Ubuntu box.

Incredibly annoying when your large project happens to use pip to install both libraries for the Python part, and tools like CMake and Conan, meaning you can't just put it all in a venv.

Re: Uv's killer feature is making ad-hoc environments easy

#334

Post by matsemann »

zahlman wrote: post #331
matsemann wrote: post #275

Earlier quoted context omitted.

It's not the "runtime" that's slow for me with pip, but all the steps needed. My biggest gripe with python is you need to basically be an expert in different tools to get a random project running. Uv solves this. Just uv run the script and it works. I don't care if pip technically can do something. The fact that I explicitly have to mess around with venvs and the stuff is already enough mental overhead that I disrega…

None of GP is about what Pip can technically do. It's about what a better tool still written in Python could do. The problems you're describing, or seeing solved with uv, don't seem to be about a problem with the design of virtual environments. (Uv still uses them.) They're about not having the paradigm of making a venv transiently , as part of the code invocation; or they're about not having a built-in automation of…

Why does it matter if it's written in python or not? I want the best tooling, don't care how it's made.

Re: Uv's killer feature is making ad-hoc environments easy

#335

Post by regularfry »

zahlman wrote: post #331
matsemann wrote: post #275

Earlier quoted context omitted.

It's not the "runtime" that's slow for me with pip, but all the steps needed. My biggest gripe with python is you need to basically be an expert in different tools to get a random project running. Uv solves this. Just uv run the script and it works. I don't care if pip technically can do something. The fact that I explicitly have to mess around with venvs and the stuff is already enough mental overhead that I disrega…

None of GP is about what Pip can technically do. It's about what a better tool still written in Python could do. The problems you're describing, or seeing solved with uv, don't seem to be about a problem with the design of virtual environments. (Uv still uses them.) They're about not having the paradigm of making a venv transiently , as part of the code invocation; or they're about not having a built-in automation of…

It may not be required, but it has the virtue of existing. Now that it does, is it a problem that it's not written in Python? Especially given that they've chosen to take on managing the interpreter as well: being in a compiled language does mean that it doesn't have the bootstrap problem of needing an already functional Python installation that they need to avoid breaking.

Re: Uv's killer feature is making ad-hoc environments easy

#336

Post by brainzap »

meitham wrote: post #252
bityard wrote: post #200

I usually stay away far FAR from shiny new tools but I've been experimenting with uv and I really like it. I'm a bit bummed that it's not written in Python but other than that, it does what it says on the tin. I never liked pyenv because I really don't see the point/benefit building every new version of Python you want to use. There's a reason I don't run Gentoo or Arch anymore. I'm very happy that uv grabs pre-compi…

uv is great, but downloading and installing base python interpreter is not a good feature as it doesn’t fetch that from PSF but from a project on GitHub, that very same project says this is compiled for portability over performance, see https://gregoryszorc.com/docs/python-build-standalone/main/

that it does it automatically is weird

Re: Uv's killer feature is making ad-hoc environments easy

#337

Post by regularfry »

mdaniel wrote: post #35
stevage wrote: post #26

As 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…

The mainline ruby doesn't but tools to support virtualenvs are around. They're pretty trivial to write: https://github.com/regularfry/gemsh/blob/master/bin/gemsh

As long as you're in the ruby-install/chruby ecosystem and managed to avoid the RVM mess then the tooling is so simple that it doesn't really get any attention. I've worked exclusively with virtualenvs in ruby for years.

Re: Uv's killer feature is making ad-hoc environments easy

#338

Post by regularfry »

fny wrote: post #153
mdaniel wrote: post #35

Earlier quoted context omitted.

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…

Because you don’t need virtualenvs or ruby_modules. You can have however many versions of the same gem installed it’s simply referenced by a gemfile, so for Ruby version X you are guaranteed one copy of gem version Y and no duplicates. This whole installing the same dependencies a million times across different projects in Python and Node land is completely insane to me. Ruby has had the only sane package manager for…

"They copied ruby" is a little unfair. From memory it was some of the same individuals.

Re: Uv's killer feature is making ad-hoc environments easy

#339

Post by stevage »

fastball wrote: post #220
stevage wrote: post #26

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

Environment and dependency management in JS-land is even worse. Similar problems with runtime version management (need to use nvm for sanity, using built-in OS package managers seems to consistently result in tears). More package managers and interactions (corepack, npm, pnpm, yarn, bun). Bad package interop (ESM vs CJS vs UMD). More runtimes (Node, Deno, Bun, Edge). Then compound this all with the fact that JS doesn…

>Similar problems with runtime version management (need to use nvm for sanity, using built-in OS package managers seems to consistently result in tears).

In practice I find this a nuisance but a small one. I wish there had been a convention that lets the correct version of Node run without me manually having to switch between them.

> More package managers and interactions (corepack, npm, pnpm, yarn, bun).

But they all work on the same package.json and node_modules/ principle, afaik. In funky situations, incompatibilities might emerge, but they are interchangeable for the average user. (Well, I don't know about corepack.)

> Bad package interop (ESM vs CJS vs UMD).

That is a whole separate disaster, which doesn't really impact consuming packages. But it does make packaging them pretty nasty.

> More runtimes (Node, Deno, Bun, Edge).

I don't know what Edge is. Deno is different enough to not really be in the same game. I find it hard to see the existence of Bun as problematic: it has been a bit of a godsend for me, it has an amazing ability to "just work" and punch through Typescript configuration issues that choke TypeScript. And it's fast.

> Then compound this all with the fact that JS doesn't have a comprehensive stdlib so your average project has literally 1000s of dependencies.

I guess I don't have a lot of reference points for this one. The 1000s of dependencies is certainly true though.

Re: Uv's killer feature is making ad-hoc environments easy

#340

Post by stevage »

nosefurhairdo wrote: post #231
fastball wrote: post #220

Earlier quoted context omitted.

Environment and dependency management in JS-land is even worse. Similar problems with runtime version management (need to use nvm for sanity, using built-in OS package managers seems to consistently result in tears). More package managers and interactions (corepack, npm, pnpm, yarn, bun). Bad package interop (ESM vs CJS vs UMD). More runtimes (Node, Deno, Bun, Edge). Then compound this all with the fact that JS doesn…

Valid criticisms, but the "standard" choices all work well. Nvm is the de facto standard for node version management, npm is a totally satisfactory package manager, node is the standard runtime that those other runtimes try to be compatible with, etc. Will also note that in my years of js experience I've hardly ever run into module incompatibilities. It's definitely gnarly when it happens, but wouldn't consider this…

> I've hardly ever run into module incompatibilities

I'm not totally sure what you're referring to, but I've definitely had a number of issues along the lines of:

- I have to use import, not require, because of some constraint of the project I'm working in - the module I'm importing absolutely needs to be required, not imported

I really don't have any kind of understanding of what the fundamental issues are, just a very painful transition point from the pre-ESM world to post.

Post reply on HN