4 ms·

Overall it feels like UV is the best thing to happen to python packaging in two decades, by circumventing the endless non productive discussions on peps and ins

Overall it feels like UV is the best thing to happen to python packaging in two decades, by circumventing the endless non productive discussions on peps and instead just building something that works and is fast. In Rust naturally.

webology 1y ago
UV is great but also builds on existing PEPs. While they have the ability experiment (which is great), they also benefit from those "endless non productive discussions on peps" as you called it. I think UV proves that dedicated funding can make a huge impact on a project and benefit for the community. They are a doing a damn, good job.
- tormeh 1y ago
  They mostly took inspiration from other languages for UV. Cargo (Rust) was a huge inspiration, but they got stuff from Ruby as well, I believe. There was an episode on "the changelog" about it. Don't remember them saying anything about PEPs, although that might just be me not having listened to the entire thing. However, the Charlie Marsh was extremely insistent on the advantages of being a polyglot and hiring people with diverse programming experiences. So I think it's quite safe to assume that played a bigger role than just PEPs.
  - zahlman 1y ago
    > Don't remember them saying anything about PEPs, although that might just be me not having listened to the entire thing. However, the Charlie Marsh was extremely insistent on the advantages of being a polyglot and hiring people with diverse programming experiences. So I think it's quite safe to assume that played a bigger role than just PEPs. Not that they took inspiration from PEPs, but they sought to implement those standards (for interoperability) and have been active in the discussion of new packaging-related PEPs.
- the__alchemist 1y ago
  I can't speak for the UV team. My 2C on how I would treat the PEPs: If there is an accepted one, and implementing it doesn't go too strongly against your competing design goals, do it for compatibility. This does not imply that the PEP is driving your design, or required to make your software. It is a way to improve compatibility.
- zahlman 1y ago
  > dedicated funding can make a huge impact on a project Where does Astral's funding come from, anyway?
- nxpnsv 1y ago
  Rye was already pretty good before it was donated to astral and renamed to uv though...
  - the__alchemist 1y ago
    I wrote an earlier one (rust, inspired by Cargo, managed deps, scripts, and py versions) called PyFlow that I abandoned, because nobody used it. "Why should I use this when we have pip, pipenv, and poetry?"
    - aiiizzz 1y ago
      Programming is 80% marketing, eh?
    - zahlman 1y ago
      It probably doesn't help that there seem to be a few other projects out there with the same name or a similar name, which do completely different things.
smallmancontrov 1y ago
Yet more proof that "the best way to do anything in python is to not do it in python."
- paulddraper 1y ago
  Find something better than Django. Or matplotlib. Or PyTorch.
  - maleldil 1y ago
    PyTorch is a C++ project with a Python wrapper.
  - aeve890 1y ago
    >Find something better than Django Rails. QED.
    - paulddraper 1y ago
      Rails is a good project no doubt. Django comes batteries included for basic apps, including an admin.
      - aeve890 1y ago
        Counterpoint, you still need a 3rd party library to implement a sane rest API in Django. Same with async jobs.
        paulddraper 1y ago
        I would definitely not use Django to do REST API. It can work...but that's not what it was designed for.
  - deleted 1y ago
    [deleted]
- deleted 1y ago
  [deleted]
scrollaway 1y ago
Can someone explain why UV is so praised when Poetry achieved a lot of that good several years earlier? Maybe I missed the train but I’ve been using poetry since its first version and all the benefits people praise UV for have long been in my builds.
- mixmastamyk 1y ago
  Ruff was the gateway drug for me, much better than the black/isort/etc combo. Led me to try uv, which fixed a couple of egregious bugs in pip. Add speed and it’s a no brainer. I don’t think poetry has these advantages, and heard about bugs early on. Is that completely fair? Probably not. But it’s obvious astral tools have funding and a competent team.
- Game_Ender 1y ago
  Speed and simplicity. Now I can fetch one binary on a system and in seconds fetch everything needed to run a Python tool or work on a code base. I can do all that without having to even worry about virtual ends, or Python versions too.
- zahlman 1y ago
  Poetry was in some senses before its time; people were frustrated with pip, but didn't really understand the problems they were encountering, meanwhile the ecosystem had started trying to move away from doing everything with Setuptools for everyone. There's a ton that I'd love to explain here about the history of pyproject.toml etc. but the point is that Poetry had its own idea about what it would mean to be an all-in-one tool... and so did everyone else. Meanwhile, the main packaging people had been designing standards with the expectation of making a UNIX-style tool ecosystem work. Everyone seems to like uv's answer better, but I'm still a believer in composable toolchains, since I've already been using those forever. I actually was an early Poetry adopter for a few reasons. In particular, I would have been fine sticking with Setuptools for building projects if it had supported PEPS 517/518/621 promptly. 621 came later but Poetry's workaround was nicer than Setuptools' to me. And it was easier to use with the new pyproject.toml setup, and I really wanted to get away from the expectation of using setup.py even for pure-Python projects. But that was really it. The main selling point point of Poetry was (and is) that they offered a lockfile and dependency resolution, but these weren't really things I personally needed. So there was nothing really to outweigh the downsides: * The way Poetry does the actual installation is, as far as I can tell, not much different from what pip does. And there are a ton of problems with that model. * The early days of Poetry were very inconsistent in terms of installation and upgrade procedures. There was at least once that it seemed that the only thing that would work was a complete manual uninstall and reinstall, and I had to do research to figure out what I had to remove for the uninstallation as there was nothing provided to automate that. * In the end, Poetry didn't have PEP 621 support for about four years (https://github.com/python-poetry/roadmap/issues/3 https://github.com/python-poetry/roadmap/issues/3 ; the OP was already almost a year after PEP acceptance in https://discuss.python.org/t/_/5472/109 https://discuss.python.org/t/_/5472/109); there was this whole thing about how you were supposed to use pyproject.toml to describe the basic metadata of your project for packaging purposes, but if you used Poetry then you used Masonry to build, and that meant using a whole separate metadata configuration. Setuptools was slow in getting PEP 621 support off the ground (and really, PEP 621 itself was slow! It's hard to justify expecting anyone to edit pyproject.toml manually without PEP 621!), but Poetry was far slower still. I had already long given up on it at that point. So for me, Poetry was basically there to provide Masonry, and Masonry was still sub-par. I was still creating venvs manually, using `twine` to upload to PyPI etc. because that's just how I think. Writing something like `poetry shell` (or `uv run`) makes about as much sense to me as `git run-unit-tests` would.
frizlab 1y ago
Yeah yeah, in rust… You know rust is not the only language in which one can write good code, right?
- zx8080 1y ago
  Good point! What are the other peoper languages in addition to golang and maybe c++ for such tooling? However people... don't like (hate? fear?) c++ nowadays. And I doubt that golang fits well here. So what else? (I'm not pushing towards rust! It just seems rust got into some vacuum, however not fitting it fully like a square thing in a round hole.)
  - frizlab 1y ago
    That I’m sure of: Swift is extremely underrated and actually very close functionally to rust. I don’t know other languages, but I’ve heard a lot of good things about zig.
    - zx8080 1y ago
      > swift Not everyone would want to get into Apple vendor-locked language (formally not, but it's like saying Chromium is opensource and not related to Alphabet/Google) and its development environment. Especially after JetBrains closed its swift oriented ide [0]. I hate xcode, sorry, after developing for too many years in it. 0: https://www.jetbrains.com/objc/ https://www.jetbrains.com/objc/
      - frizlab 1y ago
        Swift has an open-source and fully supported first party LSP integration and VSCode plugin, as well as a very active and welcoming community (forums). Using Swift w/o Xcode is now 100% possible and very much recommended by some people when no Apple development-platform specifics are required (native iOS/macOS apps). The language was initially very much Apple-platforms oriented (had to be), but now that pretty much all the Apple stuff works well they moved beyond that. Finally where the language comes from does not impact whether you can write good code with it.

webology 1y ago

UV is great but also builds on existing PEPs. While they have the ability experiment (which is great), they also benefit from those "endless non productive discussions on peps" as you called it. I think UV proves that dedicated funding can make a huge impact on a project and benefit for the community. They are a doing a damn, good job.

tormeh 1y ago
They mostly took inspiration from other languages for UV. Cargo (Rust) was a huge inspiration, but they got stuff from Ruby as well, I believe. There was an episode on "the changelog" about it. Don't remember them saying anything about PEPs, although that might just be me not having listened to the entire thing. However, the Charlie Marsh was extremely insistent on the advantages of being a polyglot and hiring people with diverse programming experiences. So I think it's quite safe to assume that played a bigger role than just PEPs.
- zahlman 1y ago
  > Don't remember them saying anything about PEPs, although that might just be me not having listened to the entire thing. However, the Charlie Marsh was extremely insistent on the advantages of being a polyglot and hiring people with diverse programming experiences. So I think it's quite safe to assume that played a bigger role than just PEPs. Not that they took inspiration from PEPs, but they sought to implement those standards (for interoperability) and have been active in the discussion of new packaging-related PEPs.
the__alchemist 1y ago
I can't speak for the UV team. My 2C on how I would treat the PEPs: If there is an accepted one, and implementing it doesn't go too strongly against your competing design goals, do it for compatibility. This does not imply that the PEP is driving your design, or required to make your software. It is a way to improve compatibility.
zahlman 1y ago
> dedicated funding can make a huge impact on a project Where does Astral's funding come from, anyway?
nxpnsv 1y ago
Rye was already pretty good before it was donated to astral and renamed to uv though...
- the__alchemist 1y ago
  I wrote an earlier one (rust, inspired by Cargo, managed deps, scripts, and py versions) called PyFlow that I abandoned, because nobody used it. "Why should I use this when we have pip, pipenv, and poetry?"
  - aiiizzz 1y ago
    Programming is 80% marketing, eh?
  - zahlman 1y ago
    It probably doesn't help that there seem to be a few other projects out there with the same name or a similar name, which do completely different things.

smallmancontrov 1y ago

Yet more proof that "the best way to do anything in python is to not do it in python."

paulddraper 1y ago
Find something better than Django. Or matplotlib. Or PyTorch.
- maleldil 1y ago
  PyTorch is a C++ project with a Python wrapper.
- aeve890 1y ago
  >Find something better than Django Rails. QED.
  - paulddraper 1y ago
    Rails is a good project no doubt. Django comes batteries included for basic apps, including an admin.
    - aeve890 1y ago
      Counterpoint, you still need a 3rd party library to implement a sane rest API in Django. Same with async jobs.
      - paulddraper 1y ago
        I would definitely not use Django to do REST API. It can work...but that's not what it was designed for.
- deleted 1y ago
  [deleted]
deleted 1y ago
[deleted]

scrollaway 1y ago

Can someone explain why UV is so praised when Poetry achieved a lot of that good several years earlier? Maybe I missed the train but I’ve been using poetry since its first version and all the benefits people praise UV for have long been in my builds.

mixmastamyk 1y ago
Ruff was the gateway drug for me, much better than the black/isort/etc combo. Led me to try uv, which fixed a couple of egregious bugs in pip. Add speed and it’s a no brainer. I don’t think poetry has these advantages, and heard about bugs early on. Is that completely fair? Probably not. But it’s obvious astral tools have funding and a competent team.
Game_Ender 1y ago
Speed and simplicity. Now I can fetch one binary on a system and in seconds fetch everything needed to run a Python tool or work on a code base. I can do all that without having to even worry about virtual ends, or Python versions too.
zahlman 1y ago
Poetry was in some senses before its time; people were frustrated with pip, but didn't really understand the problems they were encountering, meanwhile the ecosystem had started trying to move away from doing everything with Setuptools for everyone. There's a ton that I'd love to explain here about the history of pyproject.toml etc. but the point is that Poetry had its own idea about what it would mean to be an all-in-one tool... and so did everyone else. Meanwhile, the main packaging people had been designing standards with the expectation of making a UNIX-style tool ecosystem work. Everyone seems to like uv's answer better, but I'm still a believer in composable toolchains, since I've already been using those forever. I actually was an early Poetry adopter for a few reasons. In particular, I would have been fine sticking with Setuptools for building projects if it had supported PEPS 517/518/621 promptly. 621 came later but Poetry's workaround was nicer than Setuptools' to me. And it was easier to use with the new pyproject.toml setup, and I really wanted to get away from the expectation of using setup.py even for pure-Python projects. But that was really it. The main selling point point of Poetry was (and is) that they offered a lockfile and dependency resolution, but these weren't really things I personally needed. So there was nothing really to outweigh the downsides: * The way Poetry does the actual installation is, as far as I can tell, not much different from what pip does. And there are a ton of problems with that model. * The early days of Poetry were very inconsistent in terms of installation and upgrade procedures. There was at least once that it seemed that the only thing that would work was a complete manual uninstall and reinstall, and I had to do research to figure out what I had to remove for the uninstallation as there was nothing provided to automate that. * In the end, Poetry didn't have PEP 621 support for about four years (https://github.com/python-poetry/roadmap/issues/3 https://github.com/python-poetry/roadmap/issues/3 ; the OP was already almost a year after PEP acceptance in https://discuss.python.org/t/_/5472/109 https://discuss.python.org/t/_/5472/109); there was this whole thing about how you were supposed to use pyproject.toml to describe the basic metadata of your project for packaging purposes, but if you used Poetry then you used Masonry to build, and that meant using a whole separate metadata configuration. Setuptools was slow in getting PEP 621 support off the ground (and really, PEP 621 itself was slow! It's hard to justify expecting anyone to edit pyproject.toml manually without PEP 621!), but Poetry was far slower still. I had already long given up on it at that point. So for me, Poetry was basically there to provide Masonry, and Masonry was still sub-par. I was still creating venvs manually, using `twine` to upload to PyPI etc. because that's just how I think. Writing something like `poetry shell` (or `uv run`) makes about as much sense to me as `git run-unit-tests` would.

frizlab 1y ago

Yeah yeah, in rust… You know rust is not the only language in which one can write good code, right?

zx8080 1y ago
Good point! What are the other peoper languages in addition to golang and maybe c++ for such tooling? However people... don't like (hate? fear?) c++ nowadays. And I doubt that golang fits well here. So what else? (I'm not pushing towards rust! It just seems rust got into some vacuum, however not fitting it fully like a square thing in a round hole.)
- frizlab 1y ago
  That I’m sure of: Swift is extremely underrated and actually very close functionally to rust. I don’t know other languages, but I’ve heard a lot of good things about zig.
  - zx8080 1y ago
    > swift Not everyone would want to get into Apple vendor-locked language (formally not, but it's like saying Chromium is opensource and not related to Alphabet/Google) and its development environment. Especially after JetBrains closed its swift oriented ide [0]. I hate xcode, sorry, after developing for too many years in it. 0: https://www.jetbrains.com/objc/ https://www.jetbrains.com/objc/
    - frizlab 1y ago
      Swift has an open-source and fully supported first party LSP integration and VSCode plugin, as well as a very active and welcoming community (forums). Using Swift w/o Xcode is now 100% possible and very much recommended by some people when no Apple development-platform specifics are required (native iOS/macOS apps). The language was initially very much Apple-platforms oriented (had to be), but now that pretty much all the Apple stuff works well they moved beyond that. Finally where the language comes from does not impact whether you can write good code with it.