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

Uv overtakes pip in CI

wagtail.org

Post reply on HN
Print view View original

161–170 of 184 posts

Re: Uv overtakes pip in CI

#161

Post by famouswaffles »

kstrauser wrote: post #143
emeraldd wrote: post #138

Earlier quoted context omitted.

> by letting you just make another environment This is actually what I'm talking about .. Why do I need a whole new python environment rather than just scoping the dependencies of an application to that application? That model makes it significantly harder to manage multiple applications/utilities on a machine, particularly if they have conflicting package versions etc. Being able to scope the dependencies to a speci…

> Why do I need a whole new python environment rather than just scoping the dependencies of an application to that application? But… that’s what a virtualenv is . That’s the whole reason it exists. It lets you run 100 different programs, each with its own different and possibly conflicting dependencies. And yeah, those dependencies are completely isolated from each other.

I think his point is that you could have just had a situation where multiple versions of the same dependency could be installed globally rather than creating a new isolation each time.

Re: Uv overtakes pip in CI

#162

Post by Grimblewald »

tyg13 wrote: post #118
hyperbovine wrote: post #107

Earlier quoted context omitted.

uv is so over-the-top fast compared to what we're used to that I would argue it's actually bad for the language. Suddenly it dawns on you that by far the most capable and performant package manager (and linter) (and code formatter) (and type checker) for Python is in fact not written in Python. Leaves an odd taste. Makes you wonder what else ought not be written in Python ... or why anything should be written in Pyth…

IMO, Python should only be used for what it was intended for: as a scripting language. I tend to use it as a kind of middle ground between shell scripting and compiled languages like Rust or C. It's a truly phenomenal language for gluing together random libraries and data formats, and whenever I have some one-off task where I need to request some data from some REST API, build a mapping from the response, categorize…

Also great for rapid prototyping, but one needs to be real with oneself, it is a prototype.

Re: Uv overtakes pip in CI

#163

Post by robertlagrant »

slyall wrote: post #127
hyperbovine wrote: post #107

Earlier quoted context omitted.

uv is so over-the-top fast compared to what we're used to that I would argue it's actually bad for the language. Suddenly it dawns on you that by far the most capable and performant package manager (and linter) (and code formatter) (and type checker) for Python is in fact not written in Python. Leaves an odd taste. Makes you wonder what else ought not be written in Python ... or why anything should be written in Pyth…

Well Python isn't written in python either.

CPython is written in C, but PyPy is written in RPython, at least.

Technically Python, the language spec, is written in English.

Re: Uv overtakes pip in CI

#164

Post by philipallstar »

walkabout wrote: post #82
kstrauser wrote: post #78

Earlier quoted context omitted.

I’m certain there’s going to be so bizarre edge case where pip is fine and uv isn’t. It’s inevitable. However, in every situation where I’ve used it, pip is better than pip or poetry or any other package manager I’ve ever used. I just found out they’re still making pipenv. Yes, if you’re using pipenv, I’m confident that uv will be a better experience in every way, except maybe “I like using pipenv so I can take long…

Yeah, I’m just skeptical because I was at an agency in the heat of yarn-mania, waaaay after people online were proclaiming npm dead and pointless, and it went poorly enough that we developed a ha-ha-only-serious joke that you knew a project was properly in-development when someone had lost a half-day debugging some really weird error only to find that “npm install” instantly fixed it, and then switched the started-in…

The Javascript tool wars were a lot more emotional and cargo-culty than anything in the Python space I can think of.

Re: Uv overtakes pip in CI

#165

Post by zahlman »

emeraldd wrote: post #138
zahlman wrote: post #65

Earlier quoted context omitted.

> It has a lot of the same problems as just globally pip installing packages No, it doesn't. It specifically avoids the problem of environment pollution by letting you just make another environment. And it avoids the problem of interfering with the system by not getting added to sys.path by default, and not being in a place that system packages care about. PEP 668 was specifically created in cooperation between the P…

> by letting you just make another environment This is actually what I'm talking about .. Why do I need a whole new python environment rather than just scoping the dependencies of an application to that application? That model makes it significantly harder to manage multiple applications/utilities on a machine, particularly if they have conflicting package versions etc. Being able to scope the dependencies to a speci…

> Why do I need a whole new python environment rather than just scoping the dependencies of an application to that application?

If you haven't before, I strongly encourage you to try creating a virtual environment and inspecting what it actually contains.

"A whole new Python environment" is literally just a folder hierarchy and a pyvenv.cfg file, and some symlinks so that the original runtime executable has an alternate path. (On Windows it uses some stub wrapper executables because symlinks are problematic and .exe files are privileged; see e.g. https://paul-moores-notes.readthedocs.io/en/latest/wrappers.... .) And entirely unnecessary activation scripts for convenience.

If you wanted to be able to put multiple versions of dependencies into an environment, and have individual applications see what they need and avoid conflicts, you'd still need folders to organize stuff and config data to explain which dependencies are for which applications.

And you still wouldn't be able to solve the diamond dependency problem because of fundamental issues in the language design (i.e modules are cached, singleton objects).

When you make a virtual environment you don't do anything remotely like "duplicating the rest of the Python environment". You can optionally configure it to "include" the base environment's packages by having them added to sys.path.

Re: Uv overtakes pip in CI

#166

Post by saghm »

om8 wrote: post #144
saghm wrote: post #80

Earlier quoted context omitted.

As someone who also hasn't really used any of the past 8 years or so of Python dependency management, it's nice that it seems to support using arbitrary other tooling as well. At some point recently I wanted to run something that happened to use pdm, which I hadn't even heard of, but I was able to invoke it with `uv tool run pdm` and not have to learn anything about how to set it up manually.

FYI you can run just `uvx pdm`

Interesting! I honestly didn't even know that this shorthand existed

Re: Uv overtakes pip in CI

#167

Post by mnky9800n »

anitil wrote: post #48
bognition wrote: post #3

This shouldn’t be a surprise to anyone who has been using Python and has tried uv. Python dependency management and environments have been a pain for 15 years. Poetry was nice but slow and sometimes difficult. Uv is lightning fast and damn easy to use. It’s so functional and simple.

For me the most convincing argument was that it took ~3 minutes to go from 'I wonder if I should give this thing a try' to 'oh it .... it worked!?'

This is how I explain it to the stragglers. Just try it because you will suddenly in about 1 to 3 minutes not know how to go back. Haha.

Re: Uv overtakes pip in CI

#168

Post by Alir3z4 »

simonw wrote: post #87
Alir3z4 wrote: post #68

Earlier quoted context omitted.

Ooooh that's a neat one. I really like the hard links. On my machine, there are like 100s of not thousands of venvs. I simply have all of them under ~/.python_venvs/ / Does that mean, no matter how many projects I install pytorch and tensoflow and huggingface and all the heavy machinery, they'll be counted only once as long as they're unique? If that's the case, then I can leave my habit of pip and move to uv. This i…

"Does that mean, no matter how many projects I install pytorch and tensoflow and huggingface and all the heavy machinery, they'll be counted only once as long as they're unique?" I think so, based on my understanding of how this all works. You may end up with different copies for different Python versions, but it should still save you a ton of space.

Just an update for whoever ends up on this comment.

This feature works as long as your venv that uv creates and the uv cache (in user home directory, or anywhere else that is configured to keep the cache folder) are both on the same filesystem.

The drive where the venv was created was NTFS and the user home directory where uv cache exists was ext4 file system.

Therefore the caching didn't work and a warning was shown by uv hinting to the problem.

Re: Uv overtakes pip in CI

#169

Post by wishitwerentso »

simonw wrote: post #22
torben-friis wrote: post #10

As an outsider to python, I never got how a language who got popular for being simple, elegant and readable could end up with perhaps the most complex tooling situation (dependencies, envs, etc). Any time I glance at the community there seems to be a new way of doing things. What caused python to go through these issues? Is there any fundamental design flaw ?

It's mostly about age. Python has been around for 35 years now. The first version of a Python package directory was the cheeseshop (Monthy Python reference) in 2003. The earliest version of a pip-like tool was "easy_install" which - I kid you not - worked by scraping the HTML listing page of the cheeseshop and downloading zip files linked from that! More recent languages like Node.js and Rust and Go all got to create…

35 years is misleading. Python existed, yes, but was very different. e.g. Pandas was released in 2008. Most use packages much more recent than that. 35 years ago Perl was faster than Python and had deep adoption (through 2007? or so)

Re: Uv overtakes pip in CI

#170

Post by 112233 »

icar wrote: post #147
112233 wrote: post #145

I'm at the point where I don't touch python without uv at all, if possible. The only bad is, now I want to use uv to install go and java and debian packages too ... :( The ability to get random github project working without messing with system is finally making python not scary to use.

You might be interested in mise [0]: mise use -g go@1.24 mise use -g java@latest mise use -g github:BurntSushi/ripgrep [0]: https://mise.jdx.dev/

This looks .. epic. How comes it has flown under my radar, feels like finding gnome village in your car glovebox. Thank you for the mention!
Post reply on HN