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

411–420 of 428 posts

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

#411

Post by rat87 »

zahlman wrote: post #405
rat87 wrote: post #393

Earlier quoted context omitted.

Lots of reasons starting. You may want many people to have the same point release. They have early builds without needing to compile it from source and have free threading (mogul) builds. I think they might even have pro builds. Not to mention that not all district releases will have the right python release. Also people want the same tool to handle both python version and venv creation and requirement installation

>Also people want the same tool to handle both python version and venv creation and requirement installation This is the part I don't understand. Why should it be the same tool? What advantage does that give over having separate tools?

Because its easier. Because it fits together nicer and more consistently. Also because UV is well written and written in rust so all the parts are fast. You can recreate a venv from scratch for every run.

Also as silly as it is I actually have a hard time remembering the venv syntax each time.

uv run after a checkout with a lock file and a .python-version file downloads the right python version creates a venv and then installs the packages. No more needing throwaway venvs to get a clean pip freeze for requirements. And I don't want to compile python, even with something helping me compile and keep track of compiles like pyenv a lot can go wrong.

And that assumes an individualindividual project run by someone who understands python packaging. UV run possibly in a wrapper script will do those things for my team who doesn't get packaging as well as I do. Just check in changes and next time they UV run it updates stuff for them

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

#412

Post by zahlman »

rat87 wrote: post #411
zahlman wrote: post #405

Earlier quoted context omitted.

>Also people want the same tool to handle both python version and venv creation and requirement installation This is the part I don't understand. Why should it be the same tool? What advantage does that give over having separate tools?

Because its easier. Because it fits together nicer and more consistently. Also because UV is well written and written in rust so all the parts are fast. You can recreate a venv from scratch for every run. Also as silly as it is I actually have a hard time remembering the venv syntax each time. uv run after a checkout with a lock file and a .python-version file downloads the right python version creates a venv and the…

I guess I will never really understand the aesthetic preferences of the majority. But.

>Because its easier. Because it fits together nicer and more consistently. Also because UV is well written and written in rust so all the parts are fast. You can recreate a venv from scratch for every run.

This is the biggest thing I try to push back on whenever uv comes up. There is good evidence that "written in Rust" has quite little to do with the performance, at least when it comes to creating a venv.

On my 10-year-old machine, creating a venv directly with the standard library venv module takes about 0.05 seconds. What takes 3.2 more seconds on top of that is bootstrapping Pip into it.

Which is strange, in that using Pip to install Pip into an empty venv only takes about 1.7 seconds.

Which is still strange, in that using Pip's internal package-installation logic (which one of the devs factored out as a separate project) to unpack and copy the files to the right places, make the script wrappers etc. takes only about 0.2 seconds, and pre-compiling the Python code to .pyc with the standard library `compileall` module takes only about 0.9 seconds more.

The bottleneck for `compileall`, as far as I can tell, is still the actual bytecode compilation - which is implemented in C. I don't know if uv implemented its own bytecode compilation or just skips it, but it's not going to beat that.

Of course, well thought-out caching would mean it can just copy the .pyc files (or hard-link etc.) from cache when repeatedly using a package in multiple environments.

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

#413

Post by IanCal »

zahlman wrote: post #332
IanCal wrote: post #322

Earlier quoted context omitted.

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

Ah thank you for the correction, that makes sense - it seemed very odd for a minor version release.

I think a lot of people probably have strong memories of all the nonsense that earlier pip versions resulted in, I know I do. I didn't realise this was a more solved problem now as not seeing an infrequent issue is hard to notice.

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

#414

Post by tomtom1337 »

mrbonner wrote: post #111
nharada wrote: post #12

I really like uv, and it's the first package manager for a while where I haven't felt like it's a minor improvement on what I'm using but ultimately something better will come out a year or two later. I'd love if we standardized on it as a community as the de facto default, especially for new folks coming in. I personally now recommend it to nearly everyone, instead of the "welllll I use poetry but pyenv works or you…

+1 uv now also supports system installation of python with the --default --preview flags. This probably allows me to replace mise (rtx) and go uv full time for python development. With other languages, I go back to mise.

I use mise with uv for automatic activation of venvs when I cd into a directory containing one (alongside a mise.toml). Do you tackle this in some other manner?

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

#415

Post by hobofan »

krick wrote: post #303
mk12345 wrote: post #289

Earlier quoted context omitted.

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

If I read [1] correctly, it seems it checks against lockfile, not pyproject.toml. So it seems like it won't help if I change pyproject.toml manually. Which is a big inconveniece, if so. Whatever, I think I'll try it for myself later today. It's long overdue.

Most uv commands will (unless otherwise instructed like e.g. with --frozen) by default update your lockfile to be in sync with your pyproject.toml.

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

#416

Post by mixmastamyk »

lmm wrote: post #408
mixmastamyk wrote: post #406

Earlier quoted context omitted.

There are simply few, I don't shy away from them. Other than tools replaced by ruff, httpie, twine, ptpython, yt-dlp, and my own tools I don't need anything else. Most "user" tools are provided by the system package manager. All the other project-specific things go in venvs where they belong. This is all a non-issue despite constant "end of the world" folks who never learned sysadmin and are terrified of an error. If…

> This is all a non-issue despite constant "end of the world" folks who never learned sysadmin and are terrified of an error. It's not a non-issue. Yes it's not a showstopper, but it's a niggling drag on productivity. As someone who's used to the JVM but currently having to work in Python, everything to do with package management is just harder and more awkward than it needs to be (and every so often you just get stu…

It’s not a drag if you ignore it and it doesn’t happen even once a decade.

Still I’m looking forward to uv because I’ve lost faith in pypa. They break things on purpose and then say they have no resources to fix it. Well they had the resources to break it.

But this doesn’t have much to do with installing tools into ~/.local.

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

#417

Post by mrbonner »

tomtom1337 wrote: post #414
mrbonner wrote: post #111

Earlier quoted context omitted.

+1 uv now also supports system installation of python with the --default --preview flags. This probably allows me to replace mise (rtx) and go uv full time for python development. With other languages, I go back to mise.

I use mise with uv for automatic activation of venvs when I cd into a directory containing one (alongside a mise.toml). Do you tackle this in some other manner?

Did you mean using mise to install uv? I never thought of this before. Do you have a reference somewhere of how it works? Thx

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

#418

Post by fastasucan »

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…

uv helps prevent some of that using caching https://docs.astral.sh/uv/concepts/cache/#cache-directory

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

#419

Post by sbene970 »

riwsky wrote: post #52

Heck, 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've started a repo with some of these scripts, the most recent one being my favorite: a wrapper for Microsoft AutoGen's very recent Magentic-1, a generalist LLM-Multi-Agent-System. It can use the python code, the CLI, a browser (Playwright) and the file system to complete tasks.

A simple example a came across is having to rename some files:

1. you just open the shell in the location you want

2. and run this command:

uv run https://raw.githubusercontent.com/SimonB97/MOS/main/AITaskRu... "check the contents of the .md files in the working dir and structure them in folders"

There's a link to Magentic-1 docs and further info in the repo: https://github.com/SimonB97/MOS/tree/main/AITaskRunner (plus two other simple scripts).

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

#420

Post by camel_Snake »

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…

I believe pixi, by the same group (astral) is the better comparison to conda.

https://pixi.sh/latest/build/getting_started/

Post reply on HN