Rye: A Vision Continued(lucumr.pocoo.org) |
Rye: A Vision Continued(lucumr.pocoo.org) |
I had to guess, that’s the path that the Astral team would take as well - expand ruff’s capabilities so it can do everything a Python developer needs. So the vision that Armin is describing here might be achieved by ruff eventually. They’d have an advantage that they’re not a single person maintenance team, but the disadvantage of needing to show a return to their investors.
Poetry and Rye mostly do the same things, but Rye additionally does Python version management. I was personally recently reminded* that not only should one use dedicated environments for their projects, but also lock their specific Python versions.
I've used Rye so far for Python/package/env management, and it does the job just fine.
* (I upgraded from Fedora 38 to Fedora 39, which also bumped the system Python version from 3.11 to 3.12. And all of my virtual environments said boom.) :')
Otoh it’s definitely newer and there are still rough edges from time to time.
If I start a new project using Poetry, every contributor will need to install and use Poetry, since it breaks a lot of Python standards and has its own syntax for things like package version dependencies.
If i start using Rye, nobody else has to use Rye unless they want to, the project just has a: - requirements-dev.lock and requirements.lock file - pyproject.toml file - that's it.
Torch at least is easy to pip install, as is poetry if you skip all the versions that were mispackaged.
It's unclear to me what the benefit of conda is these days, other than making it much harder to reproduce your environment on other machines.
I haven't tried Rye yet, mostly because from my (outsider's) perspective, Python version management is better handled externally like rvm, rbenv, or chruby for Ruby or rustup for Rust; I have recently shifted to using mise (formerly rtx) because unlike asdf it does not use shims by default.
Is there a good case for Rye over PDM if you leave out Python version management?
Rye is a one stop shop for everything that I need.
https://chriswarrick.com/blog/2023/01/15/how-to-improve-pyth... https://xkcd.com/927/
"I did not feel well throwing yet another Python packaging tool into the ring.
Yet it exists now and has user. (sic)"
TL;DR: I knew it was a bad idea, but I did it anyway.
But I wouldn't have had to, anyway. Because I know how names work: "Rye" is not in the set of current named tools. Doesn't matter that it wraps them. It becomes one by doing so, and now we have 15.
Improving documentation, spreading the word, giving feedback. Honestly anything helps.
If you click into their link "Should Rye Exist" [1] you'll see that XKCD 927 is literally the first sentence and full width image.
Chris Warrick has done a ton of thinking - and a lot of writing [1] - on the subject and has very sage things to say about it. But unlike the author, he didn't decide to write another one. Because there are many good reasons not to. Thanks for letting me know you didn't bother reading that follow-up though: pretty clear who is providing zero value here :shrug:
[1] In fact, here's more he has to say about it: https://chriswarrick.com/blog/2024/01/15/python-packaging-on...
-- https://chriswarrick.com/blog/2024/01/15/python-packaging-on...
