Darian Moody
Armin RonacherSince quite a few people asked me about my **rye** "package solution" for Python, I put it on GitHub. https://github.com/mitsuhiko/rye — it's written in Rust and just wraps pip/pip-tools and virtualenv. Also auto installs Python for you. It's a bit of my dream of what Python packaging could be.
Hugo 雨果@mitsuhiko Why can't it just use the distribution's Python? What kind of distro is missing a binary python package? I feel like we're living in different universes! 😅
Jan Katins@whynothugo @mitsuhiko one^Wsome reasons I would guess: because on a mac with python from brew, every venv based on a version which got updated, breaks, so you have to rebuild it. And in debian you need extra packages to get a working pip. And sometimes I would like to pin a specific minor version...
The workflow here makes so much sense... I read the pep for "python as package" today, that would basically replace the one used by rye if I understand it correctly.
@jankatins @mitsuhiko If you update your Python version then you need to rebuild your virtualenv anyway because some packages contain binary bits that might not be compatible.
@whynothugo @mitsuhiko in a python minor version update when only using wheels?
poswald@whynothugo @mitsuhiko I would personally flip this from “why can’t it just use…” to “why not isolate to a known…” For that reason I think this is the right choice for a long-lived project. It’s not about having a python available in the distro as much as it’s about exerting more control over your env.
@poswald @mitsuhiko I'm not sure I fully understand the use case. You want to indefinitely maintain a specific version of Python (e.g.: the one you'd use on production), but you're fine with all other dependencies (e.g.: anything that's not python or python packages) being updated?
I've worked on projects where a specific python was desirable to match production, but usually using docker of a VM was the solution because it made sense to pin everything else too.
@whynothugo @mitsuhiko ah ok. Yeah if the solution is docker then you’re grabbing control at a lower level. You just need one clean way to install on your chosen OS that works. Hopefully it doesn’t break too much from version to version. That’s not a bad thing but it’s also understandable why people who operate at the language level want more consistent control of their envs.
@mitsuhiko @poswald Yeah, that makes sense. I mostly can't imagine what kind of project requires such fine grained control for a single dependency but is completely flexible with all others.
@whynothugo For a start because of the amount of hacks needed to support Debian pythons. They are a huge source of a growing number of hacks landing in pip and friends.
@mitsuhiko If the Python distro packages for Debian have issues, have you though of providing Debian packages with a working/current Python (or using some stable third-party repo)?
Do you think that explicitly declaring the minor version (e.g. `python3.11` as a hashbang) could help?
@mitsuhiko would you take a pr which creates releases with binaries (e.g. on tags or even on each commit to main)?
Gaétan Lepage 
@mitsuhiko FYI I packaged rye in nixpkgs 🙂 : https://github.com/NixOS/nixpkgs/pull/227834
@mitsuhiko I'm using pip-tools and mkvirtualenv. I wanna try rye out, since it sounds like you've oiled out a lot of the annoying manual work. But my target often IS the system Python.
@whynothugo You can register a system python with it:
rye toolchain register /path/to/system/python
> rye toolchain register /usr/bin/python3
error: No such file or directory (os error 2)
> /usr/bin/python3 --version
Python 3.11.3
@whynothugo can you open an issue? I will have a look. Also add better error reporting. It’s very lacking.