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.
Rye: A Vision Continued
31–40 of 45 posts
Re: Rye: A Vision Continued
#32Earlier quoted context omitted.
How does Rye compare to Poetry?
Here's a handy Venn diagram which shows where Rye currently sits in the ecosystem: https://alpopkes.com/posts/python/figures/venn_diagram.png 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 Pyth…
I adamantly believe that software projects should never rely on system dependencies. It’s just a totally broken concept and fundamentally bad idea, imho.
Re: Rye: A Vision Continued
#33Earlier quoted context omitted.
LOL I surely did, it even explicitly says: "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. [1] https://github.com/mitsuhiko/rye/discussions/6
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:
[1] In fact, here's more he has to say about it: https://chriswarrick.com/blog/2024/01/15/python-packaging-on...
Re: Rye: A Vision Continued
#34Earlier quoted context omitted.
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. [1] https://github.com/mitsuhiko/rye/discussions/6
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. Than…
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.
Re: Rye: A Vision Continued
#35Earlier quoted context omitted.
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. [1] https://github.com/mitsuhiko/rye/discussions/6
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. Than…
[deleted]
Re: Rye: A Vision Continued
#36Earlier quoted context omitted.
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. Than…
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.
-- https://chriswarrick.com/blog/2024/01/15/python-packaging-on...
Re: Rye: A Vision Continued
#37Earlier quoted context omitted.
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. -- https://chriswarrick.com/blog/2024/01/15/python-packaging-on...
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.
Re: Rye: A Vision Continued
#38Not 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.
If you have to question yourself that then you seriously lack experience with the language.
Re: Rye: A Vision Continued
#39I 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?
Re: Rye: A Vision Continued
#40I 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…
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.