How we standardized editable installs PEP 660 vs PEP 662
summary
PEP-660 wins: editable installs become a formalized API that pushes most work to build back-ends via new methods so back-ends produce the artifacts an installer can use; installers keep the same workflow. An alternative, PEP-662 front-end metadata, would have let front ends map modules to files (symlinks, pth, import hooks) but loses central control. The community takes five years to agree, back-ends rapidly implement the new API, and setuptools still lags.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 1:33Editable installation basics
- 4:48History of editable installs
- 8:37Issues with previous methods
- 11:21Technical challenges
- 14:01New solutions and approaches
- 17:20Python build systems
- 19:21PEP 660 and 662
- 23:58PEP 660 implementation
- 25:47Lessons and future challenges
related talks
26mWhat does PEP 517 mean for packaging
32mInside the Cheeseshop: How Python Packaging Works
24mInside the Cheeseshop:How Python Packaging Works
25mInside the Cheeseshop: How Python Packaging Works
30mThe Evolutionary Saga of Python Packaging
17mHow Python Evolves: The Role of Python Enhancement Proposals (PEPs)
34mAdventures in pip land
26mDependency Management in Python