PPC nomination AMA for Henry Schreiner

Packaging PPC nominations
1

Hi all,

I’m going to join in the AMA for packaging council nomination too. You can see my statement here: Nominee for 2026 Python Packaging Council Election | Python.org. It’s pretty light-weight, though, so hopefully this will be a chance to cover anything you’d like to ask me about.

If we haven’t met (either digitally or at PyCon/SciPy, etc), I’m a Princeton Research Software Engineer (RSE) and maintainer on lots of packages (see https://iscinumpy.dev) for PyPA (packaging, cibuildwheel, build, etc.), scikit-build (scikit-build-core, cmake, ninja, dynamic-metadata), pybind (pybind11 and it’s examples), scikit-hep (High Energy Physics, if you are curious; my focus there is on histogramming and supporting the ecosystem, especially compiled packages), and a smattering of other packages, like nox, flake8-lazy, and plumbum. I also wrote most of the Scientific-Python development guide, the current iteration of the packaging tutorial (with the tabs), PEP 808, and quite a bit of other course / workshop material. I also maintain quite a few conda-forge packages.

My interests are, roughly sorted:

  • Security: I’m very interested in securing and protecting our maintainers. See the work in sp-repo-review, and I’ve got more plans too!
  • Ease of use: I’ve worked extensively to make getting things that are hard (compiled extensions for Python) easy to approach for newcomers (pybind11 + scikit-build-core + cibuildwheel, for example). I also teach extensively. Getting started should be easy.
  • Scaling up: Making sure tools (like cibuildwheel and scikit-build-core) that start simple are able to handle the demands of large packages like PyTorch via thoughtful configuration
  • Enabling power users: We should enable the hardest use cases without punishing beginners. I’m very excited about wheel variants (experimental support is in scikit-build-core 1.0), default extras, etc. People should be able to choose and not be forced.
  • Performance: Faster is better. uv is great, but if we can speed up the native tools too, everyone benefits regardless of the tool they pick. See my performance post on packaging, for example.
  • Minimal churn: Things that work should continue to work unless there isn’t any other way to go forward. See scikit-build-core’s minimum version setting, which when set keeps a package building identically on future versions of scikit-build-core. If we break stuff, there should be a deprecation period and warnings.

Feel free to ask me anything! (though I’m about to travel a bit, so be patient for answers after Monday. :slight_smile: )

Handy link: Announcing the Packaging Council Election Candidates for 2026! | Python Insider

10 Likes
2

Hi Henry, Thanks for nominating for the PPC.

Through your work on tooling and documentation, along with Scientific Python and pyOpenSci, we’ve come a long way in the past few years for making a package easier for both pure Python builds and those with C-extensions / Rust, etc. In addition to continued improvement here, what are some ideas to make things easier for end-users who are installing packages?

It’s still difficult to explain to end users how to combine tools to support environments that are using GPUs, plugins, and different operating systems. What are your thoughts on improving the end user experience?

3

Thanks for the question! This is an important question, and a tricky one, otherwise we’d have solved it already!

For documentation, I think we can improve the experience; the python packaging guide is behind compared to efforts such as scientific python development guide, and Tim Hopper’s excellent packaging guide. There’s a split in how to handle a “blessed” guide, though: should you just pick one tool, or show multiple tools? I tend toward the latter, using tabs. I’d like to see pip/uv tabs be more common in the guide. I know some prefer avoiding any choice, but I think tabs keeps it clear (pick one, choice doesn’t matter) while meeting people where they are (maybe they already have uv or already have pip). You can see that philosophy in the current packaging.python.org page, and the scientific python pages.

I’d also like to see some of the pages that are unmaintained removed with redirects to useful pages. I there there’s also a bit of an issue with the standards spec and new-user documentation sitting side by side; making an edit to the standards spec requires careful signify, but updating the user docs is the same. Maybe we can separate this, so the spec part requires a council vote, but edits to the tutorial require less.

I’d love to see more progress toward an all-in-one experience (uv is doing really well here, also hatch and pdm). I know standardizing things like tasks is really hard (I’m still working on splitting sessions into tasks and environment in nox!), but I’d love to see attempts continue; we’ve made a lot of progress, and we have new requirements now (like any specification we come up with should be implementable in other languages like Rust). I’ve been really happy with `uv run` picking up the `dev` dependency group by default; on almost every projects I work on, `uv run pytest` just works, zero setup. It’s great. I’d like to see more of that. Pixi’s task system is really good.

I’d like to see pipx install / uv tool install (or pipx run / uvx) become more common. We still tend to tell people to pip install, followed by “oh, of course you shouldn’t have done what we told you to do” when things break. I’d love to see Python make this easier - a built in way to run PEP 723 scripts would be great for newcomers.

I’m also excited for Wasm; that basically removes all user packaging and lets the developer package and ship something in an environment everyone already has (a browser). I’d love to see support improve and tutorials include live code; PyEmscripten was a big step the right direction there.

One big change is happening; will newcomers even be reading tutorials anymore, or will they just ask agents to install things? How do we help a newcomer running an AI doing things like pip installing into user directories without asking? (I don’t have a good answer, to be honest, but it’s good to think about.)

For the second part, which I’ll summarize as “difficult environments”, I think we the wheel next project has been making good progress on this. They have the beginnings of a solution with wheel variants. There are also efforts to improve interoperability with conda and system environments. I think a lot of this is something we can work on so that users have an easier time in the future. Developers should have clear and easy to use tools (like cibuildwheel) that can build things like GPU enabled packages, and installers should be able to download the right thing using variants. I think it’s a problem that is solvable via standards and tools supporting them. Default extras is another one that helps beginners get a good environment without extra configuration.

4 Likes
4

Given your great work on making packaging easier for the beginner to understand, in what ways do you think the PPC can make the process for introducing ideas to the packaging space more inviting? Do you see a space where there is another process that is not as heavy as the current PEP process for changes to the living spec that might not make sense as a full PEP process?

1 Like
5

Thank you for stepping up to serve on the PPC. Your background with scientific and compiled-extension brings a crucial perspective. Given your dedication to power users and performance, you already also committed to keeping things working and ease of use. If these goals conflict, which will you prioritize?

The PPC will take on an important large amount of work. How much weekly time can you commit to for the in-depth review of proposed PEPs that don’t touch your preferred interests?