2 ms·
Author here. > However it’s very opinionated and ignores several things I like to have control over (and have needed to use in the past) and most importantly I
by the_mitsuhiko 4y ago
Author here.
> However it’s very opinionated and ignores several things I like to have control over (and have needed to use in the past) and most importantly I want to be able to compile my own python binary and pyenv makes it pretty painless.
For what it's worth I do agree with this, and in fact before I published this to GitHub, rye was capable of doing that. I somewhat intentionally stripped it down a bit to better explain and showcase what I wish that experience looked like.
In an ideal world, we would not have to use custom Python installations because a tool like rye could automatically fetch it. However there are always cases where you need (eg: local python builds for development etc.) so I will definitely want to bring this back.
The reason I never put this on GitHub is really that I do not want to build the next thing that just splits the ecosystem apart. But as of recent, there have been some developments that make me somewhat optimistic that there is a chance, Python packaging could be fixed once and for all, and this is supposed to be a bit of a teaser of what could be.
- santiagobasulto 4y agoArmin, thanks for rye and all you've done throughout the years. I'm curious, what are these developments you've mentioned that make you optimistic?
- the_mitsuhiko 4y agoI think the general packaging situation has sufficiently improved so that the delta to a good outcome is quite narrow. This is from both the adoption of pyproject.toml and the build ecosystem around it as well as a desire towards portable python executables. (See also the existence of PEP 711)