6 ms·

I have no relation with the Astral team but have been an early and aggressive adopter of everything they've released and it's all been easy, fast, and ergonomic

by jmduke 2y ago

I have no relation with the Astral team but have been an early and aggressive adopter of everything they've released and it's all been easy, fast, and ergonomic. Over the past eighteen months I've: 1. Replaced `flake8` with `ruff`; 2. Replaced `black` with `ruff`; 3. Replaced `pip` with `uv`; 4. Replaced `poetry` with `uv`. Their next project appears to be exactly what I _wish_ their next project to be — a replacement for pyright et al (https://github.com/astral-sh/ruff/discussions/10581 https://github.com/astral-sh/ruff/discussions/10581). Type checking is my least favorite part of my Python toolchain at the moment; I can't wait to take it for a spin.

adhamsalama 2y ago
What benefits does uv have over poetry?
- the_mitsuhiko 2y ago
  Speed, compatibility, ergonomics, standards compliance.
  - baggiponte 2y ago
    also a whole bunch of new features (--script mode), speed of development, a stacked team.
- jasongill 2y ago
  uv also manages the Python version as well, and it doesn't require jumping through hoops and hacking to get it to play nicely with Docker. uv is much more of a production-ready setup than pip or poetry from my experience moving to uv over the last few weeks
  - zahlman 2y ago
    I really haven't been able to understand why "managing the Python version" is such a big value add for so many people. I just have each version built from source and make venvs from them as needed.
    - jasongill 2y ago
      Because most people don't build their toolchain from source anymore. When I am trying to help a junior programmer get up and going, it's a lot easier to say "OK, just do `brew install uv` then `uv sync` in the project folder and you are all set" than to try to walk them through building from source. Not to mention being able to have reproducible builds for deployments, CI/CD, etc. The fact that the Python version is picked up from the project's package configuration is nice because then you don't have to remember to update the source build to match when you update pyproject.toml for a new Python release.
      - zahlman 2y ago
        I happen to have built the interpreters (not an entire toolchain) from source. But I could equally well have obtained them from a PPA or whatever else. On Windows I could have used the official installers. The point is that once I have base environments, creating venvs is trivial. (And really, the experience of building Python from source on Mint was about as smooth as I could have ever hoped for.) >when you update pyproject.toml for a new Python release. ? I don't upper-cap the Python version (or anything else without a well-defined reason - https://iscinumpy.dev/post/bound-version-constraints/ https://iscinumpy.dev/post/bound-version-constraints/ ) so I wouldn't be updating anyway. If I want to test under a new Python version then I need to write that out explicitly somewhere regardless; might as well do it on the command line.
- throwaway314155 2y ago
  Works with pytorch.
- dagw 2y ago
  In addition to what everybody else has mentioned, uv plays nice with other people's build tools. I use scikit-build-core for building most of my python packages and making scikit-build-core play nicely with poetry was somewhere between very hard and impossible. UV trivially lets me combine the two so I can let uv do what it does best (manage and install python versions and dependencies) and then have it get out of the way and let scikit-build-core take over and do what it does best.
anentropic 2y ago
It's not clear to me that they are building an alternate type checker per se Seems like `ruff server` is an LSP?
- baggiponte 2y ago
  Yes but only for linting (the flake8 rules etc). The end goal is to have proper type checking and, I think, proper LSP refactoring capabilities.
frou_dh 2y ago
Pyright was itself a big improvement over Mypy. Just look at this for starters: https://htmlpreview.github.io/?https://github.com/python/typing/blob/main/conformance/results/results.html https://htmlpreview.github.io/?https://github.com/python/typ... If Astral can leapfrog Pyright too, great. But I think it will be significantly harder than leapfrogging Flake8 and Black was.
baggiponte 2y ago
they are working on it! the internal name is currently red-knot (you can see it in their GH History and in the discord). First thing is a type checker, I think, then the renaming capabilities and such.
roland35 2y ago
Pylance is nicer than pyright, but unfortunately I don't think you can use it outside of vs code
- joshSzep 2y ago
  pylance is pyright under the hood, isn't it? it's the main reason I use pyright over mypy: I work in VSCode and I want compatible type checking
antman 2y ago
True, what I would really need is a uv based pyinstaller alternative

by jmduke 2y ago

adhamsalama 2y ago

What benefits does uv have over poetry?

the_mitsuhiko 2y ago
Speed, compatibility, ergonomics, standards compliance.
- baggiponte 2y ago
  also a whole bunch of new features (--script mode), speed of development, a stacked team.
jasongill 2y ago
uv also manages the Python version as well, and it doesn't require jumping through hoops and hacking to get it to play nicely with Docker. uv is much more of a production-ready setup than pip or poetry from my experience moving to uv over the last few weeks
- zahlman 2y ago
  I really haven't been able to understand why "managing the Python version" is such a big value add for so many people. I just have each version built from source and make venvs from them as needed.
  - jasongill 2y ago
    Because most people don't build their toolchain from source anymore. When I am trying to help a junior programmer get up and going, it's a lot easier to say "OK, just do `brew install uv` then `uv sync` in the project folder and you are all set" than to try to walk them through building from source. Not to mention being able to have reproducible builds for deployments, CI/CD, etc. The fact that the Python version is picked up from the project's package configuration is nice because then you don't have to remember to update the source build to match when you update pyproject.toml for a new Python release.
    - zahlman 2y ago
      I happen to have built the interpreters (not an entire toolchain) from source. But I could equally well have obtained them from a PPA or whatever else. On Windows I could have used the official installers. The point is that once I have base environments, creating venvs is trivial. (And really, the experience of building Python from source on Mint was about as smooth as I could have ever hoped for.) >when you update pyproject.toml for a new Python release. ? I don't upper-cap the Python version (or anything else without a well-defined reason - https://iscinumpy.dev/post/bound-version-constraints/ https://iscinumpy.dev/post/bound-version-constraints/ ) so I wouldn't be updating anyway. If I want to test under a new Python version then I need to write that out explicitly somewhere regardless; might as well do it on the command line.
throwaway314155 2y ago
Works with pytorch.
dagw 2y ago
In addition to what everybody else has mentioned, uv plays nice with other people's build tools. I use scikit-build-core for building most of my python packages and making scikit-build-core play nicely with poetry was somewhere between very hard and impossible. UV trivially lets me combine the two so I can let uv do what it does best (manage and install python versions and dependencies) and then have it get out of the way and let scikit-build-core take over and do what it does best.

anentropic 2y ago

It's not clear to me that they are building an alternate type checker per se Seems like `ruff server` is an LSP?

baggiponte 2y ago
Yes but only for linting (the flake8 rules etc). The end goal is to have proper type checking and, I think, proper LSP refactoring capabilities.

frou_dh 2y ago

Pyright was itself a big improvement over Mypy. Just look at this for starters: https://htmlpreview.github.io/?https://github.com/python/typing/blob/main/conformance/results/results.html https://htmlpreview.github.io/?https://github.com/python/typ... If Astral can leapfrog Pyright too, great. But I think it will be significantly harder than leapfrogging Flake8 and Black was.

baggiponte 2y ago

they are working on it! the internal name is currently red-knot (you can see it in their GH History and in the discord). First thing is a type checker, I think, then the renaming capabilities and such.

roland35 2y ago

Pylance is nicer than pyright, but unfortunately I don't think you can use it outside of vs code

joshSzep 2y ago
pylance is pyright under the hood, isn't it? it's the main reason I use pyright over mypy: I work in VSCode and I want compatible type checking

antman 2y ago

True, what I would really need is a uv based pyinstaller alternative