Armin @mitsuhiko Ronacher
Seeding Change and Lessons Learned
The Catch in Rye
Slide 2
Slide 2 text
Who am I?
Armin @mitsuhiko Ronacher
Things you might know I worked on: Flask,
Werkzeug, Jinja, Pygments, Sphinx, LogBook,
itsdangerous, Click, MarkupSafe, Sentry, Babel, …
Slide 3
Slide 3 text
… and then I disappeared …
Slide 4
Slide 4 text
So what did I do?
Poured a lot of time into Sentry
Started to enjoy the green pastures of Rust
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
Rust
A language empowering everyone
to build reliable and ef
fi
cient software.
• Let's not kid ourselves: it's bloody complicated
• Yet as a programmer you're surprisingly productive with it
• The ecosystem has excellent DX
• The language values backwards compatibility
• The language values innovation and progress
Slide 7
Slide 7 text
Going back in Time (~2014)
• I picked up Rust properly when I used Python 2 actively
• Cargo was not yet a thing
• Python 3 was in a state of very slow and painful adoption
Slide 8
Slide 8 text
The Zen of Python
“There should be one — and
preferably only one — obvious
way to do it.”
Slide 9
Slide 9 text
The Zen of Python (cont.)
“Special cases aren't special
enough to break the rules.”
Slide 10
Slide 10 text
Packaging de
fi
nitely isn't a
special case
Slide 11
Slide 11 text
I Saw The Light
• Packaging doesn't have to be painful
• Downloading the compiler/interpreter doesn't have to be painful
• Switching between compiler/interpreter versions can be trivial
• One can have the same experience on Linux, macOS, and Windows
Slide 12
Slide 12 text
Meet Rye!
Slide 13
Slide 13 text
No content
Slide 14
Slide 14 text
No content
Slide 15
Slide 15 text
No content
Slide 16
Slide 16 text
• The only goal is to dominate
• If it does not dominate, something else should
• “I just want it solved”
Slide 17
Slide 17 text
0 to 100
Slide 18
Slide 18 text
No content
Slide 19
Slide 19 text
Getting Pythons
Slide 20
Slide 20 text
No content
Slide 21
Slide 21 text
Lockfiles
Slide 22
Slide 22 text
No content
Slide 23
Slide 23 text
Virtual Env Management
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
• I do not work for Astral
• I gave Rye's stewardship to Astral
• uv — today — is a replacement for pip-tools/pip/venv
• uv tomorrow will fully replace the need of Rye by absorbing it in spirit
Slide 26
Slide 26 text
Does it work?
• Yes, but there are issues
• Many of the issues are not technical challenges
Slide 27
Slide 27 text
So what the the challenges?
• Dev Dependencies
• Local Dependencies
• Workspaces
• pyproject.toml Limitations (PEP 508)
• Single Version Resolution
• Good Python Builds
Slide 28
Slide 28 text
Resolver is Solved
uv is pretty damn fast. You should use it.
Slide 29
Slide 29 text
Dev Dependencies
• Every Tool invents dev dependencies
• Some could bene
fi
t from isolation
• black, ru
ff
, …
• Others do not work with isolation
• pytest, …
• Others are mixed
•
fl
ake8, …
Slide 30
Slide 30 text
Dev Dependencies
• There is no standard, everyone invents one
• Potential solution:
• reserve a "dev" extra group
• add a "tool" dependency group?
Slide 31
Slide 31 text
Local Dependencies
• How do you depend on a local package?
Slide 32
Slide 32 text
Local Dependencies
• What about temporary overrides?
• What about editable installs?
• No standard relative path URL syntax
• Potential solution: adjacent con
fi
g to override packages
Slide 33
Slide 33 text
Workspaces
• Multi-dependency projects are important
Slide 34
Slide 34 text
Workspaces
• But they don't work well yet
• They are Rye proprietary
• Again run into challenges with relative paths
Slide 35
Slide 35 text
pyproject.toml Limitations
• Dependency string array is too limiting
• Where do you store dependency
attached meta information?
• Impossible to encode even more
into these strings without breaking
already existing tools
• Who can write these strings?
Slide 36
Slide 36 text
pyproject.toml Limitations
• Why do you need meta information?
• Pick the right index (PyPI vs internal)
• Git checkout, local paths, multi-version matches
• Tool speci
fi
c proprietary (even if
only temporary) extra information
Slide 37
Slide 37 text
Other Issues with pyproject.toml
• Dynamic metadata is a bad idea
• Already countless of proprietary extensions by di
ff
erent tools
• Many di
ff
erent ways to de
fi
ne licenses
• Complex resolutions caused by markers
Slide 38
Slide 38 text
Portable Locking
• rye/uv support experimental
universal locking
• it does not yet have a stable and
supported cross platform lock format
• The problem is “not easy”
Slide 39
Slide 39 text
Single Version Resolution
• a >= 1
• a < 1
• How can you ever
fi
nd a solution?
• Rust/Node: permits multi-version resolutions
• Issues: sys.modules (though solvable), C-extension modules (CABI)
Slide 40
Slide 40 text
Technically Solvable
• https://github.com/mitsuhiko/multiversion/
• Demonstration of multi-version imports on Python 2
• What would be the bene
fi
t? Smoother ecosystem upgrades
Slide 41
Slide 41 text
Good Python Builds
• We need PEP 711: PyBI: a standard format for distributing Python
Binaries
• indygreg builds are great, but have portability
issues (bad CFLAGS, missing readline, …)
• Not an o
ff i
cial project, run by a single person