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

131–140 of 184 posts

Re: Uv overtakes pip in CI

#131

Post by daemonologist »

kstrauser wrote: post #78
walkabout wrote: post #74

Earlier quoted context omitted.

Is this like when everyone on here had already been saying Yarn was a no-brainer replacement for npm, having totally obsoleted it, for like two-plus years, but it was still lacking safety/sanity checks, missing features, and broke in bizarre ways on lots of packages in-the-wild? Or is the superior replacement actually up to the job this time?

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…

There is! The company I work for uses a weird version of Azure Devops for reason, and pip can authenticate and install packages from its artifact feeds while uv cannot. We use uv for development speed (installing internal packages from source) and then switch to pip for production builds.

Re: Uv overtakes pip in CI

#132

Post by rcleveng »

hyperbovine wrote: post #107
hk1337 wrote: post #100

Earlier quoted context omitted.

It’s a little too fast, I’m having trouble believing it’s actually doing anything sometimes.

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…

I'd rather write python than rust personally, and I also don't mind if anything performance critical is written in rust.

Letting each language do what it does best is really ideal, I'm glad that python has a great FFI, I wish golang did.

Speaking of golang, the typescript compiler is now written in it. Another case of using each language for it's strengths.

Re: Uv overtakes pip in CI

#133

Post by kstrauser »

daemonologist wrote: post #131
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…

There is! The company I work for uses a weird version of Azure Devops for reason, and pip can authenticate and install packages from its artifact feeds while uv cannot. We use uv for development speed (installing internal packages from source) and then switch to pip for production builds.

This doesn't work? https://docs.astral.sh/uv/guides/integration/alternative-ind...

Re: Uv overtakes pip in CI

#134

Post by ipnon »

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.

And it's killer use case today that is artificial intelligence development really uses it as a glue language for CUDA and similar GPU APIs.

Re: Uv overtakes pip in CI

#137

Post by atoav »

noosphr wrote: post #119
atoav wrote: post #111

Earlier quoted context omitted.

Ever had customers deploy your project on 4 different debian versions without docker? Probably not, because there are problems lurking you didn't even know could exist. And 99% of them are gone with uv.

The most unbelievable part of this story is that anyone using four versions of Debian has enough money to be customers to someone.

So you say I am lying?

Re: Uv overtakes pip in CI

#138

Post by emeraldd »

zahlman wrote: post #65
emeraldd wrote: post #7

Earlier quoted context omitted.

This is still a complete pain to work with. Virtualenv in general is a "worst of worlds" solution. It has a lot of the same problems as just globally pip installing packages, requires a bit of path mangling to work right, or special python configs, etc. In the past, it's also had a bad habit of leaking dependencies, though that was in some weird setups. It's one of the reasons I would recommend against python for muc…

> 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 specific code base without having to duplicate the rest of the python environment would be much better than a new virtualenv.

Re: Uv overtakes pip in CI

#139

Post by WhyNotHugo »

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.

uv is weird. It's like 5 entirely different tools mashed and entangled into one program.

Last I tried it, it insisted on downloading a dynamically linked Python and installing that. This obviously doesn't work, you can't distribute dynamically linked binaries for Linux and expect them to work on any distribution (I keep seeing this pattern and I guess it's because this typically works on macOS?).

Moreover my distribution already has a package manager which can install Python. I get that some absolute niche cases might need this functionality, but that should most definitely be a separate tool. The problem isn't just that the functionality is in the same binary, but also that it can get triggered when you're using another of its functionalities.

I wish this had been made into actual separate tools, where the useful ones can be adopted and the others ignored. And, most important, where the ecosystem can iterate on a single tool. Having "one tool that does 5 things" makes it really hard to iterate on a new tools that does only one of those things in a better way.

It's pretty disappointing to see the Python ecosystem move in this direction.

Re: Uv overtakes pip in CI

#140

Post by noosphr »

atoav wrote: post #137
noosphr wrote: post #119

Earlier quoted context omitted.

The most unbelievable part of this story is that anyone using four versions of Debian has enough money to be customers to someone.

So you say I am lying?

I'm saying they have much bigger problems than what python package manager they are using.
Post reply on HN