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

351–360 of 428 posts

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

#351

Post by globular-toast »

bennofs wrote: post #341
globular-toast wrote: post #305

Earlier quoted context omitted.

Yes, which is why it's silly to do it. Developers (not "users"!) need to learn how to install Python on their system. I honestly don't know how someone can call themselves a Python developer if they can't even install the interpreter!

I for one enjoy the convenience of automatically installing python versions. Yes I know how to do it manually. Yes it is possible to install multiple versions. But that does not mean I want to do it every time, just to test how things behave in different python versions. For that, it's also okay if it does not install the most performant version of the interpreter.

Sure. We've had system package managers for decades. I install a major version once a year and it gets automatically upgraded to the latest patch version by my system package manager, just like everything else.

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

#353

Post by linsomniac »

mkl wrote: post #125
linsomniac wrote: post #112

Earlier quoted context omitted.

I don't think this IS a PEP, I believe it is simply something the uv tool supports and as far as Python is concerned it is just a comment.

https://peps.python.org/pep-0723/

Thank you for the pointer, I had searched for it but couldn't find it. (edit: Glad I spent the downvotes to get educated :-)

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

#354

Post by cpburns2009 »

poincaredisk wrote: post #14
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…

I never used anything other than pip. I never felt the need to use anything other than pip (with virtualenv). Am I missing anything?

I'm fairly minimalist when it comes to tooling: venv, pip, and pip-tools. I've started to use uv recently because it resolves packages significantly faster than pip/pip-tools. It will generate a "requirements.txt" with 30 packages in a few seconds rather than a minute or two.

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

#355

Post by remram »

zahlman wrote: post #270
remram wrote: post #175

Earlier quoted context omitted.

This works until you need to upgrade something, pip might upgrade to a broken set of dependencies. Or if you run on a different OS and the dependencies are different there (because of env markers), your requirements file won't capture that. There are a lot of gotchas that pip can't fix.

> pip might upgrade to a broken set of dependencies. I'm only aware of examples where it's the fault of the packages - i.e. they specify dependency version ranges that don't actually work for them (or stop working for them when a new version of the dependency is released). No tool can do anything about that on the user's end. > Or if you run on a different OS and the dependencies are different there (because of env m…

You can specify markers in the requirements file you write, not in the frozen requirements from 'pip freeze'. Because it's just a list of what's installed on your machine.

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

#356

Post by jshen »

zahlman wrote: post #248
jshen wrote: post #240

Earlier quoted context omitted.

> Well, sure; Pip can't respect a version pin that doesn't exist anywhere in your project. If the specific version of Pandas you want says that it's okay with a range of Numpy versions, then of course Pip has freedom to choose one of those versions. If that matters, you explicitly specify it Nearly every other language solves this better than this. What your suggesting breaks down on large projects.

>Nearly every other language solves this better than this. "Nearly every other language" determines the exact version of a library to use for you, when multiple versions would work, without you providing any input with which to make the decision? If you mean "I have had a more pleasant UX with the equivalent tasks in several other programming languages", that's justifiable and common, but not at all the same. >What y…

What's your process for ensuring all members of a large team are using the same versions of libraries in a non trivial python codebase?

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

#357

Post by CGamesPlay »

zahlman wrote: post #308
CGamesPlay wrote: post #217

I want to like uv, but unfortunately there's some kind of technical distinction between a Python "package manager" and a "build system". Uv doesn't include a "build system", but encourages you to use some other one. The net result is that external dependencies don't build the same as on Poetry, don't work, and uv points the finger at some other dependency. I do hope the situation changes one day. Python packaging is…

It's not "some sort of technical distinction". Package managers are for keeping track of which pieces of code you need in your project's environment. Build systems are for... building the code, so that it can actually be used in an environment. Usually, you can directly make a pre-built wheel, and then an installer like Pip or uv can just unpack that into the environment. If it needs to be build on the user's machine…

Maybe the docs are misleading? Seems that if I want my package to be installed, I need to pick a build system, regardless of if I am using any native code. https://docs.astral.sh/uv/concepts/projects/init/#packaged-a...

> Package managers are for keeping track of which pieces of code you need in your project's environment. Build systems are for... building the code, so that it can actually be used in an environment.

This probably means something to the developers of the package managers and build systems, but to me, as a Python developer who wants to be able to publish a pure Python CLI program to PyPI, it seems like a distinction without a difference.

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

#358

Post by Gazoche »

driggs wrote: post #157
NeutralCrane wrote: post #43

Earlier quoted context omitted.

Couple of things. - pip doesn't handle your Python executable, just your Python dependencies. So if you want/need to swap between Python versions (3.11 to 3.12 for example), it doesn't give you anything. Generally people use an additional tool such as pyenv to manage this. Tools like uv and Poetry do this as well as handling dependencies - pip doesn't resolve dependencies of dependencies. pip will only respect versio…

Yes, generally people already use an additional tool for managing their Python executables, like their operating system's package manager: $> sudo apt-get install python3.10 python3.11 python3.12 And then it's simple to create and use version-specific virtual environments: $> python3.11 -m venv .venv3.11 $> source .venv3.11/bin/activate $> pip install -r requirements.txt You are incorrect about needing to use an addi…

Yeah, venv is really the best way to manage Python environments. In my experience other tools like Conda often create more headaches than they solve.

Sure, venv doesn't manage Python versions, but it's not that difficult to install the version you need system-wide and point your env to it. Multiple Python versions can coexist in your system without overriding the default one. On Ubuntu, the deadsnakes PPA is pretty useful if you need an old Python version that's not in the official repos.

In the rare case where you need better isolation (like if you have one fussy package that depends on specific system libs, looking at you tensorflow), Docker containers are the next best option.

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

#359

Post by wruza »

TZubiri wrote: post #225
wruza wrote: post #197

Earlier quoted context omitted.

Oh, tell us OS can’t venv itself a separate python root and keep itself away from what user invents to manage deps. This is non-explanation appealing to authority while it’s clearly just a mess lacking any thought. It just works like this. we don't have a left pad scale dependency ecosystem that makes version conflicts such a pressing issue TensorFlow.

We have virtual envs and package isolation, it's usually bloated, and third party and doesn't make for a good robust OS base, it's more an app layer. See flatpak, snapcraft. "Compares left pad with ml library backing the hottest AI companies of the cycle"

Bloated is an emotion, it's not a technical term. The related, most commonly known technical term is "DLL hell". And I absolutely love to work with flatpak, because not once in my job I thought about it, apart from looking what folder to backup.

Left pad was ten years ago. Today is 2025-01-13 and we are still discussing how good yet another python PM presumably is. Even a hottest ML library can only do so much in this situation.

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

#360

Post by fny »

regularfry wrote: post #338
fny wrote: post #153

Earlier quoted context omitted.

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.

You're right about this: apparently the same guy who wrote Bundler wrote Cargo.
Post reply on HN