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

Uv is the best thing to happen to the Python ecosystem in a decade

emily.space

Post reply on HN
Print view View original

811–820 of 1001 posts

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#811

Post by bashkiddie »

liampulles wrote: post #784
ederamen wrote: post #517

Uv is so good. I'm a curmudgeon about adopting new tooling, and tried uv with a lot of skepticism, but it was just better in every way. And even if it wasn't so polished and reliable, the raw speed makes it hard to go back to any other tool. Uv combined with type hints reaching critical mass in the Python ecosystem, and how solid PyLance is in VSCode, feels so good it has made me consider investing in Python as my pr…

I think Python has a place in many developers toolkits. I've never met anyone who hates Python (though I'm sure they exist), whereas for pretty much any other language one could mention there are much more polarizing viewpoints. (as the saying goes "Python is everyone's second favorite programming language"). The Python team needs not feel any pressure to change to compete, Python has already done quite well and foun…

raises hand I hate python.

I am a user of pip binaries. Every few years one of them breaks.

As far as I understand, developers never cared about pinning their dependencies and python is fast to deprecate stuff.

  $ uvx remt
      Built pygobject==3.54.5
      Built remt==0.11.0
      Built pycairo==1.28.0
  Installed 12 packages in 9ms
  Traceback (most recent call last):
    File "/home/user/.cache/uv/archive-v0/BLXjdwASU_oMB-R4bIMnQ/bin/remt", line 27, in 
    import remt
  File "/home/user/.cache/uv/archive-v0/BLXjdwASU_oMB-R4bIMnQ/lib/python3.13/site-packages/remt/__init__.py", line 20, in 
    import pkg_resources
  ModuleNotFoundError: No module named 'pkg_resources'

  $ uvx maybe
  × Failed to build `blessings==1.6`
  ├─▶ The build backend returned an error
  ╰─▶ Call to `setuptools.build_meta:__legacy__.build_wheel` failed (exit status:
      1)

      [stderr]
      /home/user/.cache/uv/builds-v0/.tmpsdhgNf/lib/python3.13/site-packages/setuptools/_distutils/dist.py:289:
      UserWarning: Unknown distribution option: 'tests_require'
        warnings.warn(msg)
      /home/user/.cache/uv/builds-v0/.tmpsdhgNf/lib/python3.13/site-packages/setuptools/_distutils/dist.py:289:
      UserWarning: Unknown distribution option: 'test_suite'
        warnings.warn(msg)
      error in blessings setup command: use_2to3 is invalid.

      hint: This usually indicates a problem with the package or the build
      environment.
  help: `blessings` (v1.6) was included because `maybe` (v0.4.0) depends on
        `blessings==1.6`
I heard rumors from computer vision developers that even libraries deprecate that fast.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#812

Post by cb321 »

AyanamiKaine wrote: post #658
miki123211 wrote: post #643

Earlier quoted context omitted.

I wish we had a language that had the syntax of Python (notably including operator overloading, which is absolutely critical for neural networks, ML, data science and numerical computations), the performance, compile times and concurrency support of Go, the type system flexibility of Typescript, and the native platform integration of C/C++.

Than you would probably like the Nim[1] programming language. It has the syntax of python, but transpiles to C/C++. A good type system. The main problem would probably the compiles times. Because you basically compile just C/C++ code. And of course the eco-system is much much smaller than Python. [1] https://nim-lang.org/

Nim compile+link times can be sub-100 milliseconds with tcc [1] (just saw 93 ms on my laptop) which can yield pretty reasonable edit-compile-test cycles.

The grandparent's scientific/Go interests suggests a need for a large, working ecosystem and there are probably several places in ArrayMancer which need some love for "fallback cases" to work with tcc (or elsewhere in the as you note much smaller Nim eco-system).

EDIT: E.g., for ArrayMancer you need to make stb_image.h work with tcc by adding a nim.cfg/config.nims `passC="-DSTBIW_NO_SIMD -DSTBI_NO_SIMD"` directive, though. And, of course, to optimize compile times, just generally speaking, you always want to import only exactly what you really need which absolutely takes more time/thought.

[1] https://github.com/TinyCC/tinycc

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#813

Post by alejoar »

tecoholic wrote: post #365
mk89 wrote: post #239

Earlier quoted context omitted.

I have used pip freeze > requirements.txt pip install -r requirements.txt Way before "official" lockfile existed. Your requirements.txt becomes a lockfile, as long as you accept to not use ranges. Having this in a single tool etc why not, but I don't understand this hype, when it was basically already there.

I am on the same boat. I like uv for its speed and other niceties it brings and being a single tool to manage different things. But lockfile is not that big a deal. I never got Poetry as well. Tried it in a project once and the lockfile was a pain with the merges. I didn’t spend much time, so maybe I didn’t understand the tool and workflow or whatever, but pip and pip-tools were just fine working with requirements.tx…

Hey, just so you know, newer lockfiles are meant to fully replace old ones, you shouldn't bother with solving merge conflicts on these files, just accept all the new changes always.

What you SHOULD solve are conflicts in the packages/project file. Once solved, just create a new lockfile and replace the old one.

This applies to lockfiles on any project python or non-python.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#814

Post by pjc50 »

rjzzleep wrote: post #626
ederamen wrote: post #517

Uv is so good. I'm a curmudgeon about adopting new tooling, and tried uv with a lot of skepticism, but it was just better in every way. And even if it wasn't so polished and reliable, the raw speed makes it hard to go back to any other tool. Uv combined with type hints reaching critical mass in the Python ecosystem, and how solid PyLance is in VSCode, feels so good it has made me consider investing in Python as my pr…

Am I the only one that's sad that poetry happened before pdm otherwise we might have had pdm as a standard instead of uv, addressing many of the things uv addresses without all the extra bells and whistles that make it cumbersome. I don't like the wedding between package manager and install manager. ... but then again neither pdm nor uv would have happened without poetry.

What is the distinction between "package manager and install manager"?

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#815

Post by liampulles »

bashkiddie wrote: post #811
liampulles wrote: post #784

Earlier quoted context omitted.

I think Python has a place in many developers toolkits. I've never met anyone who hates Python (though I'm sure they exist), whereas for pretty much any other language one could mention there are much more polarizing viewpoints. (as the saying goes "Python is everyone's second favorite programming language"). The Python team needs not feel any pressure to change to compete, Python has already done quite well and foun…

raises hand I hate python. I am a user of pip binaries. Every few years one of them breaks. As far as I understand, developers never cared about pinning their dependencies and python is fast to deprecate stuff. $ uvx remt Built pygobject==3.54.5 Built remt==0.11.0 Built pycairo==1.28.0 Installed 12 packages in 9ms Traceback (most recent call last): File "/home/user/.cache/uv/archive-v0/BLXjdwASU_oMB-R4bIMnQ/bin/remt"…

Be careful of attributing to python what is really the fault of python lib developers.

Having said that, our team is having to do a bunch of work to move to a new python version for our AWS serverless stuff, which is not something I'd have to worry about with Go (for example). So I agree, there is a problem here.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#816

Post by bashkiddie »

zelphirkalt wrote: post #795
Uehreka wrote: post #677

Earlier quoted context omitted.

This was always my issue with pip and venv: I don’t want a thing that hijacks my terminal and PATH, flips my world upside down and makes writing automated headless scripts and systemd services a huge pain. When I drop into a Node.js project, usually some things have changed, but I always know that if I need to, I can find all of my dependencies in my node_modules folder, and I can package up that folder and move it w…

> Python/pip though… Every time I need to containerize or setup a Python project for some arbitrary task, there’s always an issue with “Your Linux distro doesn’t support that version of Python anymore” [...] How are you containerizing Python projects? What confuses me about your statement are the following things: (1) How old must the Python version of those projects be, to not be supported any longer with any decent…

> (1) How old must the Python version of those projects be, to not be supported any longer with any decent GNU/Linux distribution?

Debian-13 defaults to Python-3.13. Between Python-3.12 and Python-3.13 the support for `pkg_config` got dropped, so pip projects like

https://pypi.org/project/remt/

break. What I was not aware of: `venv`s need to be created with the version of python they are supposed to be run. So you need to have a downgraded Python executable first.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#817

Post by [deleted] »

ghusto wrote: post #359
tomaskafka wrote: post #342

Earlier quoted context omitted.

So many times I have come onto a library or tool that would fix my problem, and then realized “oh crap, it’s in Python, I don’t want to spend few hours building a brittle environment for it only for that env to break next time I need to use it” - and went to look for a worse solution in better language.

I really don't get this. I can count on no hands the number of times I've had problems simply going "pip install cool-thing-i-found". Sure, this is just my experience, but I use Python a lot and use a lot of tools written in Python.

[deleted]

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#818

Post by codeptualize »

BrenBarn wrote: post #659

The sticking point for me is the way tools like uv and poetry build everything around the idea of a "project". I don't want a separate environment for every project, and I don't want to start by creating a project. I want to start with an environment that has stuff in it, and I start fiddling around, and gradually something comes together that eventually will be pulled out into a separate project. From what I can see…

But then you don't need uv. The pain point uv solves is projects. Different projects with different dependencies (even the same but different versions), multiple people, teams, and environments trying to run the same code.

That gets problematic if environments go out of sync, or you need different versions of python or dependencies.

So you are right, you probably won't benefit a lot if you just have one big environment and that works for you, but once you pull things in a project, uv is the best tool out there atm.

You could also just create a starter project that has all the things you want, and then later on pull it out, that would be the same thing.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#820

Post by dirkc »

hoherd wrote: post #805
mogoh wrote: post #803

Is it worth running uv inside a docker container?

Sometimes, yes, but I would say it depends a lot on your base image and project. If nothing else, it gives you a runtime environment that is identical to your development environment. Using uv at build time can dramatically reduce your build times if you properly handle the uv cache. https://docs.astral.sh/uv/guides/integration/docker/#caching It's also easy: COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/ htt…

If you are using it for your project, wouldn't you necessarily have to use it for your Docker setup as well?
Post reply on HN