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

A year of uv: pros, cons, and should you migrate

bitecode.dev

Post reply on HN
Print view View original

221–230 of 401 posts

Re: A year of uv: pros, cons, and should you migrate

#221

Post by lmm »

aaravchen wrote: post #120
code_biologist wrote: post #13

Earlier quoted context omitted.

Did they run into a hard blocker, or was it just that using version overrides was possible but painful? I started looking seriously at uv/pdm once poetry made it entirely clear they didn't intend to support version overrides [1]. uv's support for overrides seems serviceable if unsophisticated [2][3]. [1] https://github.com/python-poetry/poetry/issues/697 [2] https://docs.astral.sh/uv/concepts/resolution/#dependency-o…

The linked poetry Issue is pretty understandable why they aren't going to support it. I've honestly never heard of any dependency resolver that allows you to dynamically inject an override of a package's built in specification for an indirect dependency. Point blank, that's a packaging failure and the solution is, and always has been, to immediately yank the offending package. That said, the Python case has pretty li…

> I've honestly never heard of any dependency resolver that allows you to dynamically inject an override of a package's built in specification for an indirect dependency.

You can do it with [patch] in cargo (I think), or .exclude in SBT. In Maven you can use . In fact I can't think of a package manager that doesn't support it, it's something I'd always expect to be possible.

> Point blank, that's a packaging failure and the solution is, and always has been, to immediately yank the offending package.

Be that as it may, PyPi won't.

> It should never be on the end user to be specifying overrides of indirect dependency specifications at the top level though

It "shouldn't", but sometimes the user will find themselves in that situation. The only choice is whether you give them the tools to work around it or you don't.

Re: A year of uv: pros, cons, and should you migrate

#222

Post by mufasachan »

oefrha wrote: post #218
mufasachan wrote: post #175

Earlier quoted context omitted.

Eh, ML/scientific Python is large and not homogeneous. For code that should work on cluster, I would lean towards a Docker/container solution. For simpler dependancy use cases, pyenv/venv duo is alright. For some specific lib that have a conda package, it might be better to use conda, _might be_. One illustration is the CUDA toolkit with torch install on conda. If you need a basic setup, it would work (and takes age)…

Oh I'm not saying conda is a good solution for all ML/scientific. I was making the assertion that it's terrible for basically everything else.

My bad! As you said, this part of Python code bases is chaotic (:

Re: A year of uv: pros, cons, and should you migrate

#223

Post by lmm »

cjohnson318 wrote: post #9

Honest question: is uv more reproducible/portable than cramming your Python project into a Docker container? I've used pyenv, pip, venv, and a couple of other things, and they all work fine, at first, in simple scenarios.

> Honest question: is uv more reproducible/portable than cramming your Python project into a Docker container?

Yes (unless you use uv in your Dockerfile). I mean, a Docker container will freeze one set of dependencies, but as soon as you change one dependency you've got to run your Dockerfile again and will end up with completely different versions of all your transitive dependencies.

Re: A year of uv: pros, cons, and should you migrate

#224

Post by EdwardDiego »

0xCMP wrote: post #136
barosl wrote: post #43

A very well written article! I admire the analysis done by the author regarding the difficulties of Python packaging. With the advent of uv, I'm finally feeling like Python packaging is solved. As mentioned in the article, being able to have inline dependencies in a single-file Python script and running it naturally is just beautiful. #!/usr/bin/env -S uv run # /// script # dependencies = ['requests', 'beautifulsoup4…

I think this is an awesome feature and will probably a great alternative to my use of nix to do similar things for scripts/python if nothing else because it's way less overhead to get it running and playing with something. Nix for all it's benefits here can be quite slow and make it otherwise pretty annoying to use as a shebang in my experience versus just writing a package/derivation to add to your shell environment…

It's not a feature that's exclusive to uv. It's a PEP, and other tools will eventually support it if they don't already.

Re: A year of uv: pros, cons, and should you migrate

#225

Post by zoobab »

droelf wrote: post #164
epistasis wrote: post #138

Earlier quoted context omitted.

These are good points. But I think there needs to be an explanation why conda hasn't taken off more. Especially since it can handle other languages too. I've tried to get conda to work for me for more than a decade, at least once a year. What happens to me: 1) I can't solve for the tools I need and I don't know what to do. I try another tool, it works, I can move forward and don't go back to conda 2) it takes 20-60 m…

We've been working on all the shortcomings in `pixi`: pixi.sh It's very fast, comes with lockfiles and a project-based approach. Also comes with a `global` mode where you can install tools into sandboxed environments.

I am trying to configure Pixi to use it with Artifactory proxy in a corporate environment, still could not figure it out how to configure it.

Re: A year of uv: pros, cons, and should you migrate

#226

Post by [deleted] »

epistasis wrote: post #138
BrenBarn wrote: post #126

Like so many other articles that make some offhand remarks about conda, this article raves about a bunch of "new" features that conda has had for years. > Being independent from Python bootstrapping Yep, conda. > Being capable of installing and running Python in one unified congruent way across all situations and platforms. Yep, conda. > Having a very strong dependency resolver. Yep, conda (or mamba). The main thing…

These are good points. But I think there needs to be an explanation why conda hasn't taken off more. Especially since it can handle other languages too. I've tried to get conda to work for me for more than a decade, at least once a year. What happens to me: 1) I can't solve for the tools I need and I don't know what to do. I try another tool, it works, I can move forward and don't go back to conda 2) it takes 20-60 m…

[deleted]

Re: A year of uv: pros, cons, and should you migrate

#227

Post by code_biologist »

aaravchen wrote: post #120
code_biologist wrote: post #13

Earlier quoted context omitted.

Did they run into a hard blocker, or was it just that using version overrides was possible but painful? I started looking seriously at uv/pdm once poetry made it entirely clear they didn't intend to support version overrides [1]. uv's support for overrides seems serviceable if unsophisticated [2][3]. [1] https://github.com/python-poetry/poetry/issues/697 [2] https://docs.astral.sh/uv/concepts/resolution/#dependency-o…

The linked poetry Issue is pretty understandable why they aren't going to support it. I've honestly never heard of any dependency resolver that allows you to dynamically inject an override of a package's built in specification for an indirect dependency. Point blank, that's a packaging failure and the solution is, and always has been, to immediately yank the offending package. That said, the Python case has pretty li…

I've honestly never heard of any dependency resolver that allows you to dynamically inject an override of a package's built in specification for an indirect dependency.

npm and yarn both let you do it. PDM and uv think about it differently, but both allow overrides.

It should never be on the end user to be specifying overrides of indirect dependency specifications at the top level though, which is what was requested from the poetry tool.

I'm jealous of your upstreams. I just want to use Django package XYZ that says it's only compatible with Django 3.X on Django 4. Works just fine, but poetry won't let it happen. Upstream seems like they might literally be dead in some cases, with an unmerged unanswered PR open for years. In other cases a PR was merged but no new PyPI release was ever made because I allowed for more liberal requirements for a 0.7.X release last made in 2019 and they're on version 4.X or whatever these days.

On one decade old application I have a half dozen forks of old packages with only alterations to dependency specifications specifically to please poetry. It's really annoying as opposed to just being able to say "I know better than what this package says" like in npm and yarn.

This is exactly what half the comments in poetry's "please allow overrides" issue are saying.

Re: A year of uv: pros, cons, and should you migrate

#228

Post by sieve »

physicsguy wrote: post #214
sieve wrote: post #195

Earlier quoted context omitted.

> people don't need to work out which version of cuda/which gpu settings/libraries/etc. to use This is not true in my case. The regular pytorch does not work on my system. I had to download a version specific to my system from the pytorch website using --index-url. > packages bundle all possible options into a single artifact Cross-platform Java apps do it too. For e.g., see https://github.com/xerial/sqlite-jdbc . Bu…

Cross platform Java doesn't have the issue because the JVM is handling all of that for you. But if you want native extensions written in C you get back to the same problem pretty quickly.

> if you want native extensions written in C

The SQLite project I linked to is a JDBC driver that makes use of the C version of the library appropriate to each OS. LWJGL (https://repo1.maven.org/maven2/org/lwjgl/lwjgl/3.3.6/) is another project which heavily relies on native code. But distributing these, or using these as dependencies, does not result in hair-pulling like it does with python.

Re: A year of uv: pros, cons, and should you migrate

#229

Post by agoose77 »

epistasis wrote: post #138
BrenBarn wrote: post #126

Like so many other articles that make some offhand remarks about conda, this article raves about a bunch of "new" features that conda has had for years. > Being independent from Python bootstrapping Yep, conda. > Being capable of installing and running Python in one unified congruent way across all situations and platforms. Yep, conda. > Having a very strong dependency resolver. Yep, conda (or mamba). The main thing…

These are good points. But I think there needs to be an explanation why conda hasn't taken off more. Especially since it can handle other languages too. I've tried to get conda to work for me for more than a decade, at least once a year. What happens to me: 1) I can't solve for the tools I need and I don't know what to do. I try another tool, it works, I can move forward and don't go back to conda 2) it takes 20-60 m…

Have you used the contemporary tooling in this space? `mamba` (and ~therefore, `pixi`) is fast, and you can turn off the base environment. The UX is nicer,too!

Re: A year of uv: pros, cons, and should you migrate

#230

Post by EdwardDiego »

athrun wrote: post #106
woodruffw wrote: post #103

Earlier quoted context omitted.

Maybe I'm missing something, but why wouldn't you just pin to an exact version of `requests` (or whatever) instead? I think that would be equivalent in practice to limiting resolutions by release date, except that it would express your intent directly ("resolve these known working things") rather than indirectly ("resolve things from when I know they worked").

Pinning deps is a good thing, but it won't necessarily solve the issue of transitive dependencies (ie: the dependencies of requests itself for example), which will not be pinned themselves, given you don't have a lock file. To be clear, a lock file is strictly the better option—but for single file scripts it's a bit overkill.

1 file, 2 files, N files, why does it matter how many files?

Use a lock file if you want transitive dependencies pinned.

I can't think of any other language where "I want my script to use dependencies from the Internet, pinned to precise versions" is a thing.

Post reply on HN