I think it’s interesting that rye uses ruff (https://github.com/astral-sh/ruff) for linting and formatting. That’s the right call, and it’s also correct to bundle that in for an integrated dev experience.
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.
I just learned that "ruff fmt" exists. Why would I use that over black? I've been using black for a couple years now, I'm loathe to change but ruff has a lot of good press.
I've been using rye for all of my python projects and it has generally been great. There's a slightly annoying piece at the beginning when you first set up a project because "rye init" doesn't actually produce a valid empty project - you have to add a few lines to pyproject.toml, but it certainly beats a lot of the other things I've used.
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.) :')
I adamantly believe that software projects should never rely on system dependencies. It’s just a totally broken concept and fundamentally bad idea, imho.
Way faster to do dependency resolution for one. It also uses ruff for linting which is crazy fast also. So all in all it’s a better and more productive dev experience as far as I’m concerned. Ig also encourages you to lock down specific versions of python whuch helps prevent catastrophic dependency problems on system upgrades.
Otoh it’s definitely newer and there are still rough edges from time to time.
I think Rye and Poetry offer very similar user experiences very well, but for me what makes Rye really special is that it is just using python standard tools.
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.
I'm usually using conda (mamba) nowadays as it also has binary support so I can use cuda etc. easily for deep learning purposes. Is this something Rye can also do?
I really like Rye and have used it a lot. Lately I've been using pixi more and more because of its cross-platform locking support, since I develop on Mac and deploy mostly to Linux. It also supports all cobda packages, which can be a big advantage.
I welcome anything that brings sanity to Python packaging. I have had several projects that I have been working with and have tried Poetry, Hatch, PDM and just plain old `requirements.txt` and I have been longing for something that Just Works like Rubygems and Bundler or Mix (Elixir) or Cargo, or even something that Sort of Works like npm or yarn.
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?
Regarding one man project. I always think of contributing back to the community. But things are not at all simple. I wish developers of projects would do weekly knowledge sharing videos. Or at least record themselves going through the code.
I'm about to do a full rewrite/refactor of my flask app and will be starting fresh with Rye. I was using a cobbled together pyenv+virtualenv+bunch of other tools to manage it all, but was spending too much time on environment setup/upkeep when I was not on my main laptop.
Rye is a one stop shop for everything that I need.
This is an impressive effort, no doubt. And Python packaging is in a woeful state. But I'm sorry, the last thing the ecosystem needs it another alternative!
"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.
Your first comment irked me because it adds zero value to the discussion. You lazily threw out XKCD 927 which the Rye author explicitly mentioned themselves.
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.
I included it because the author did, and irked me by openly admitting they recognize the argument but went against it anyway. There is good reason that particular XKCD hits so hard.
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:
I'm not entirely sure what you're suggesting other than "accept the terrible status quo". For what it's worth my personal use of rye predates the release by multiple years (not in this particular manifestation) and I held off releasing it for a very long time.
> The PyPA should shut down or merge some duplicate projects, and work with the community (including maintainers of non-PyPA projects) to build One True Packaging Tool. To make things easier. To avoid writing code that does largely the same thing 5 times. To make sure thousands of projects don’t depend on tools with a bus factor of 1 or 2.
I mean, I can also try to tell the PyPA to do a thing or two but that won't magically make it work. The PyPA is a bunch of separate individuals doing their thing and they are free to listen to people or ignore them. I do not have the power (nor do I believe I should) to force them to do a specific thing.
When did you last evaluate it? I have been using ruff for advent of code (low stakes project) — last year it still felt a little beta-ish, this year it seemed more ready for prime time.
Not to dig on this project, but I find it constantly befuddling how awful the Python dev ecosystem is. And has barely improved after a decade of being so popular. The ergonomics of coding with Java or C# in 2010 are still so far beyond anything in Python in 2024, I constantly question why it's so popular.
I've been using it for many years. It's fine to start a greenfield project, but I'm at an org with 12+ years of tech debt and every generation of application has a different build system and almost all of them are brittle as dry leaves. My metric for the value of a language isn't how convenient it is write, but how durable it is in maintenance. And for my money, Python is still vastly inferior to strongly-typed languages. Build tools, doc tools, and readable stack traces outweigh syntax or semantics.
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.