09-15, 12:00–12:30 (Europe/London), Assembly Room
Packaging Python code is a thorny area, but it's getting better.
PEP 517 is a dry, technical specification for an important step:
allowing packagers to choose alternatives to setuptools.
I'll talk about how projects can take advantage of this, and the
fun of writing your own packaging tools.
Packaging has never been an easy topic in Python. PEP 517 was
hammered out over several hundred emails - sometimes heated - on
the distutils-sig mailing list. The goal: to dethrone distutils and
setuptools as the single blessed way of making Python packages.
The precise, formal language of a specification isn't exactly made
for bedtime reading. So in this talk, I'll unpack what it means for
people who want to put their code on PyPI. I was part of the discussion
to create the proposal, I've written a PEP 517 backend and a
library for frontends, so I've seen the gory details.
I'll set the context of what there was before PEP 517, and why
people wanted something better. Then I'll describe how the PEP
came about, and how it envisages different tools working together.
I'll show practical examples of how you can take advantage of PEP 517
enabled tools like Flit or enscons for packaging your own project,
and some of the difficulties existing projects might encounter in the
transition. Finally, I'll briefly go into how and why you might write
your own tools around PEP 517: either backends to build packages, or
frontends to use those packages.
Thomas is a data analysis software engineer at European XFEL, an international research facility near Hamburg. He uses Python extensively to slice and dice data, and in particular to build tools for other people to do the slicing and dicing. He also contributes to open-source projects around a variety of themes, ranging from scientific computing to Python 3 migration to packaging.