A year of uv: pros, cons, and should you migrate • Hacker News Board

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

#201

Post by procaryote » Wed, Feb 19, 2025, 8:36 AM UTC

epistasis wrote: post #59

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…

One other key part of this is freezing a timestamp with your dependency list, because Python packages are absolutely terrible at maintaining compatibility a year or three or five later as PyPI populates with newer and newer versions. The special toml incantation is [tool.uv] exclude-newer: # /// script # dependencies = [ # "requests", # ] # [tool.uv] # exclude-newer = "2023-10-16T00:00:00Z" # /// https://docs.astral.…

Oh that's neat!

I've just gotten into the habit of using only the dependencies I really must, because python culture around compatibility is so awful

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

#202

Post by isoprophlex » Wed, Feb 19, 2025, 8:40 AM UTC

epistasis wrote: post #59

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…

One other key part of this is freezing a timestamp with your dependency list, because Python packages are absolutely terrible at maintaining compatibility a year or three or five later as PyPI populates with newer and newer versions. The special toml incantation is [tool.uv] exclude-newer: # /// script # dependencies = [ # "requests", # ] # [tool.uv] # exclude-newer = "2023-10-16T00:00:00Z" # /// https://docs.astral.…

Wow, this is such an insanely useful tip. Thanks!

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

#203

Post by datadeft » Wed, Feb 19, 2025, 8:41 AM UTC

gyomu wrote: post #168

datadeft wrote: post #166

Now we should just figure out why to stop here. Why not write everything in Rust? Recently I have moved all my projects to Rust from Python and never looked back. Of course we need projects like Torch and we are not yet there, but those simpler projects that do not require GPU libraries Rust is great.

What’s a good flask (+jinja) equivalent for rust?

I use Axum and Askama for such usecases.

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

#204

Post by procaryote » Wed, Feb 19, 2025, 8:41 AM UTC

datadeft wrote: post #166

Now we should just figure out why to stop here. Why not write everything in Rust? Recently I have moved all my projects to Rust from Python and never looked back. Of course we need projects like Torch and we are not yet there, but those simpler projects that do not require GPU libraries Rust is great.

It's a lot harder to write rust than python.

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

#205

Post by datadeft » Wed, Feb 19, 2025, 8:42 AM UTC

wiseowise wrote: post #186

datadeft wrote: post #166

Now we should just figure out why to stop here. Why not write everything in Rust? Recently I have moved all my projects to Rust from Python and never looked back. Of course we need projects like Torch and we are not yet there, but those simpler projects that do not require GPU libraries Rust is great.

Maybe because there would be blood on the streets, because people would start killing each other over atrocious build times?

Interesting. So pip install times did not make them to kill each other and the result is sometimes works, but if we wait on cargo build somehow it triggers them.

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

#206

Post by hyperbrainer » Wed, Feb 19, 2025, 8:46 AM UTC

sieve wrote: post #32

IgorPartola wrote: post #26

Earlier quoted context omitted.

Sounds like a great use case for ZFS’s deduplication at block level.

I use ZFS everywhere EXCEPT on this drive. Not willing to have ZFS on the primary drive till native support lands in the kernel (so, never).

Have you tried borg [0]? Also, why not BTRFS?

[0] https://borgbackup.readthedocs.io/en/stable/index.html

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

#207

Post by stavros » Wed, Feb 19, 2025, 8:46 AM UTC

BossingAround wrote: post #196

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…

This looks horrible for anything but personal scripts/projects. For anything close to production purposes, this seems like a nightmare.

It's not meant for production.

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

#208

Post by hyperbrainer » Wed, Feb 19, 2025, 8:47 AM UTC

motorest wrote: post #129

I know good naming is hard, and there are an awful lot of project names that clash, but naming a project uv is unfortunate due to the ubiquitous nature of libuv https://libuv.org/

I think of uv in the gfx programming sense too.

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

#209

Post by BrenBarn » Wed, Feb 19, 2025, 8:52 AM UTC

wiseowise wrote: post #180

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…

https://docs.conda.io/projects/conda/user-guide/getting-star... > To bootstrap a conda installation, use a minimal installer such as Miniconda or Miniforge. > Conda is also included in the Anaconda Distribution. Bam, you’ve already lost me there. Good luck getting this approved on our locked down laptops. No pip compatibility? No venv compatibility? Into the trash it goes, it’s not standard. The beauty of uv is that…

Well, that's sort of the point though. By leaving behind the "standards" it can add benefits that aren't possible with the standards.

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

#210

Post by BrenBarn » Wed, Feb 19, 2025, 8:57 AM UTC

optionalsquid wrote: post #169

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…

Besides being much slower, and taking up much more space per environment, than uv, conda also has a nasty habit of causing unrelated things to break in weird ways. I've mostly stopped using it at this point, for that reason, tho I've still had to reach for it on occasion. Maybe pixi can replace those use cases. I really should give it a try. There's also the issue the license for using the repos, which makes it risky…

Not sure what you mean about space. Conda uses hardlinks for the most part, so environment size is shared (although disk usage tools don't always correctly report this).