this post was submitted on 16 Feb 2024
52 points (100.0% liked)

Python

6343 readers
10 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

πŸ“… Events

PastNovember 2023

October 2023

July 2023

August 2023

September 2023

🐍 Python project:
πŸ’“ Python Community:
✨ Python Ecosystem:
🌌 Fediverse
Communities
Projects
Feeds

founded 1 year ago
MODERATORS
top 13 comments
sorted by: hot top controversial new old
[–] uthredii@programming.dev 11 points 8 months ago* (last edited 8 months ago)

This actually sounds really promising!

  • They are teaming up with an existing python package manger written in rust.
  • These are the people who make/made ruff, probably the most useful and fast python linter.
  • you basically get pip from a single binary.
  • they plan to have cargo/poetry like functionality in the future.

Edit: here is a blog post from the creator of rye talking about rye and UV: https://lucumr.pocoo.org/2024/2/15/rye-grows-with-uv/

[–] exussum@lemmy.world 8 points 8 months ago (1 children)

Is pip the real bottle neck in software development? How many dependencies are you managing that require this speed?

[–] sugar_in_your_tea@sh.itjust.works 12 points 8 months ago (1 children)

The longest running tool in our toolchain is pytest, followed somewhat closely by poetry. I work on a project with several teams, so I end up needing to reinstall deps pretty frequently.

It's not something I'm actively looking for, but I wouldn't say no to some improvements. But I need the additional features of poetry, so I probably won't bother until it gets a bit more sophisticated.

[–] takeda@lemmy.world 5 points 8 months ago (1 children)

The slowness of poetry is mostly due to network bottlenecks. While a Rust based tool, might be faster, it won't be a dramatic improvement, unlike the one we have seen with Ruff.

[–] sugar_in_your_tea@sh.itjust.works 1 points 8 months ago* (last edited 8 months ago) (1 children)

True, but poetry still has a long startup time (probably reading the lock file?) before it gets to the network parts. Also, a lot of the time spent in our projects is compiling/installing dependencies, not downloading them, and at least the install part could probably be sped up (I'm guessing async Rust is faster than whatever Poetry is doing).

But yeah, I'm not expecting huge wins here, but if it saves me a minute or so when rebuilding my docker images (currently takes >5 min in the poetry part alone), that's worth taking the time to switch.

I'm a lot more excited about projects like Ruff though, but any part of the Python tooling ecosystem is interesting.

[–] SatouKazuma@lemmy.world 1 points 8 months ago (1 children)

Damn. Poetry alone takes 5 minutes in Docker rebuilds? That's good to know.

[–] sugar_in_your_tea@sh.itjust.works 2 points 8 months ago (1 children)

It does for us, ymmv. pip wasn't that much faster, so the version resolution isn't our main bottleneck, we just have a lot of packages (like 30 direct deps, and they have their own deps; seems like ~140 packages in our biggest microservice).

[–] SatouKazuma@lemmy.world 1 points 8 months ago (1 children)
[–] sugar_in_your_tea@sh.itjust.works 1 points 8 months ago (1 children)

Well, I don't need to reinstall deps very often, like every 2 weeks at most. My regular workflow is like a 5s restart of the container, and that's if something breaks with the auto-reload.

But I still wouldn't say no to some speed improvements. It's way better than our FE codebase, which takes way longer.

[–] SatouKazuma@lemmy.world 1 points 8 months ago (1 children)
[–] sugar_in_your_tea@sh.itjust.works 1 points 8 months ago (1 children)
[–] SatouKazuma@lemmy.world 1 points 8 months ago (1 children)

Ah. Thanks for clarifying, and apologies if I appeared stupid.

No worries, always happy to clarify. πŸ˜€