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

281–290 of 428 posts

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

#281

Post by claytonjy »

insane_dreamer wrote: post #241

been using conda for years with multiple projects each of which has numerous environments (for different versions). fairly large complex environments with coda, tf, jax, etc. has always worked well, and my biggest complaint - the sluggish resolver - largely addressed with mamba resolver. packages not available on conga-forge can be installed into the conda env pip. maybe I'm missing something but it's not clear to me…

It is very difficult for most conda users to maintain conda environments. They use the same env for nearly all their work, don’t understand the hierarchical nature of conda envs, don’t know which one they’re installing into, install stuff with pip without recording it in their env file, etc. The worst local environment messes i’ve ever seen always involve conda.

It can be used effectively, but does not make it easy to do so.

uv makes itself harder to misuse

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

#282

Post by zahlman »

benatkin wrote: post #188
lolinder wrote: post #187

Earlier quoted context omitted.

> The default and de facto standard should be something that doesn’t get put on a pedestal but stays out of the way. The problem is that in the python ecosystem there really isn't a default de facto standard yet at all. It's supposed to be pip, but enough people dislike pip that it's hard as a newcomer to know if it's actually the standard or not. The nice thing about putting something like this on a pedestal is that…

It feels even more standard than it used to, with python -m pip and python -m venv making it so it can be used with a virtalenv even if only python or python3 is in your path.

Just for the record, `venv` has been in since Python 3.3, although it didn't bootstrap Pip into the environment until 3.4 and wasn't the officially blessed way of doing things until 3.5 (which was still over 9 years ago).

Pip isn't part of the standard library; the standard library `ensurepip` (called from `venv`) includes a vendored wheel for Pip (https://github.com/python/cpython/tree/main/Lib/ensurepip/_b...), and imports Pip from within that wheel to bootstrap it. (Wheels are zip files, and Python natively knows how to import code from a zip file, so this just involves some `sys.path` manipulation. The overall process is a bit complex, but it's all in https://github.com/python/cpython/blob/main/Lib/ensurepip/__... .)

This is why you get prompted to upgrade Pip all the time in new virtual environments (unless you preempt that with `--upgrade-deps`). The core development team still wants to keep packaging at arms length. This also allows Pip to be developed, released and versioned independently.

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

#283

Post by zahlman »

lolinder wrote: post #191
benatkin wrote: post #188

Earlier quoted context omitted.

It feels even more standard than it used to, with python -m pip and python -m venv making it so it can be used with a virtalenv even if only python or python3 is in your path.

Oh, it's certainly more standard than it used to be, and maybe it's on the way to being fully standard. But it definitely hasn't arrived in the spot that npm, cargo, hex, bundler, and similar have in their respective ecosystems. Npm is a pretty good example of what pip should be. Npm has had to compete with other package managers for a long time but has remained the standard simply because it actually has all the bas…

Pip intentionally and by design does not cover package management. It covers package installation - which is more complex for Python than for other languages because of the expectation of being able to (try to) build code in other languages, at install time.

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

#284

Post by wiseowise »

crispyambulance wrote: post #114

I do like uv and hope to try it soon but I don't get the point of the article. Pyenv + poetry already gives you ability to "pull in local dependencies". Yes, you have to create a virtual environment and it's not "ad-hoc". But if you're going to pull in a bunch of libraries, WHY would you want to invoke python and all your work dependencies on a one liner? Isn't it much better and easier to just spell-out the dependen…

Yes! I love verbosity. It gives me job security. I’m tired of these tools making my job easier.

Previously I could allocate a whole week to setup initial scaffold for the project. Also more tools - more failure points, so I can flex on stupid juniors how smart I am. Now I can’t even go to pee with how fast and easy this freaking uv is. WTF.

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

#285

Post by claytonjy »

aizk wrote: post #58

one useful UV alias I use is uvsys='uv pip install --system' So I can just do uv {package} for a quick and dirty global install. I'm so used to pip install being global by default just making this shorthand makes things a bit easier.

this sounds like it’s asking for trouble! very easy to mess up your whole system

i would highly recommend only using —-system in a docker container or similar

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

#286

Post by zo1 »

wruza wrote: post #202
zo1 wrote: post #87

Earlier quoted context omitted.

Half the time something breaks in a javascript repo or project, every single damn javascript expert in the team/company tells me to troubleshoot using the below sequence, as if throwing spaghetti on a wall with no idea what's wrong. Run npm install Delete node_modules and wait 30minutes because it takes forever to delete 500MB worth of 2 million files. Do an npm install again (or yarn install or that third one that p…

So you’re not experiencing exactly this with pip/etc? I hit this “just rebuild this 10GB venv” scenario like twice a day while learning ML. Maybe it’s just ML, but then regular node projects don’t have complex build-step / version-clash deps either.

I think it's something unique to python's ML ecosystem, to be honest. There is a lot of up-in-the-air about how to handle models, binaries and all of that in a contained package, and that results in quite a few hand-rolled solutions, some of which encroach on the package manager's territory, plus of course drivers and windows.

I've worked on/with some fairly large/complex python projects, and they almost never have any packaging issues that aren't just obvious errors by users. Yes, every once in a while we have to be explicit about a dependency because some dependent project isn't very strict with their versioning policy and their API layers.

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

#287

Post by zahlman »

krick wrote: post #259

Ok, this must be a dumb question answered by the manual, but I still haven't got my hands on uv, so: but does it solve the opposite? I mean, I pretty much never want any "ad-hoc" environments, but I always end up with my .venv becoming an ad-hoc environment, because I install stuff while experimenting, not bothering to patch requirements.txt, pyproject.toml or anything of the sort. In fact, now I usually don't even b…

>installing stuff automatically changes pyprpject.toml (or whatever the standard will be with uv)

pyproject.toml represents an inter-project standard and Charlie Marsh has committed to sticking with it, along with cooperating with future Python packaging PEPs. But while you can list transitive dependencies, specify exact versions etc. in pyproject.toml, it's not specifically designed as a lockfile - i.e., pyproject.toml is meant for abstract dependencies, where an installer figures out transitively what's needed to support them and decides on exact versions to install.

The current work for specifying a lockfile standard is https://peps.python.org/pep-0751/ . As someone else pointed out, uv currently already uses a proprietary lockfile, but there has been community interest in trying to standardize this - it just has been hard to find agreement on exactly what it needs to contain. (In the past there have been proposals to expand the `pyproject.toml` spec to include other information that lockfiles often contain for other languages, such as hashes and supply-chain information. Some people are extremely against this, however.)

As far as I know, uv isn't going to do things like analyzing your codebase to determine that you no longer need a certain dependency that's currently in your environment and remove it (from the environment, lock file or `pyproject.toml`). You'll still be on the hook for figuring out abstractly what your project needs, and this is important if you want to share your code with others.

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

#288

Post by zahlman »

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 very same project says this is compiled for portability over performance

Realistically, the options on Linux are the uv way, the pyenv way (download and compile on demand, making sure users have compile-time dependencies installed as part of installing your tool), and letting users download and compile it themself (which is actually very easy for Python, at least on my distro). Compiling Python is not especially fast (around a full minute on my 4-core, 10-year-old machine), although I've experienced much worse in my lifetime. Maybe you can get alternate python versions directly from your distro or a PPA, but not in a way that a cross-distro tool can feasibly automate.

On Windows the only realistic option is the official installer.

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

#289

Post by mk12345 »

krick wrote: post #259

Ok, this must be a dumb question answered by the manual, but I still haven't got my hands on uv, so: but does it solve the opposite? I mean, I pretty much never want any "ad-hoc" environments, but I always end up with my .venv becoming an ad-hoc environment, because I install stuff while experimenting, not bothering to patch requirements.txt, pyproject.toml or anything of the sort. In fact, now I usually don't even b…

I think it does! uv add [0] adds a dependency to your pyproject.toml, as well as your environment.

If you change your pyproject.toml file manually, uv sync [1] will update your environment accordingly.

[0]: https://docs.astral.sh/uv/guides/projects/#managing-dependen... [1]: https://docs.astral.sh/uv/reference/cli/#uv-sync

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

#290

Post by zahlman »

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.

When was the last time you saw a NodeJS package that expects to be able to compile Fortran code at installation time?

If you want Numpy (one of the most popular Python packages) on a system that doesn't have a pre-built wheel, you'll need to do that. Which is why there are, by my count, 54 different pre-built wheels for Numpy 2.2.1.

And that's just the actual installation process. Package management isn't solved because people don't even agree on what that entails.

The only way you avoid "worry about modifying the global environment" is to have non-global environments. But the Python world is full of people who refuse to understand that concept. People would rather type `pip install suspicious-package --break-system-packages` than learn what a venv is. (And they'll sometimes do it with `sudo`, too, because of a cargo-cult belief that this somehow magically fixes things - spoilers: it's typically because the root user has different environment variables.)

Which is why this thread happened on the Python forums https://discuss.python.org/t/the-most-popular-advice-on-the-... , and part of why the corresponding Stack Overflow question https://stackoverflow.com/questions/75608323 has 1.4 million views. Even though it's about an error message that was carefully crafted by the Debian team to tell you what to do instead.

Post reply on HN