Python Developer Tooling Handbook – Packaging

Bernát Gábor's Recap of the 2026 Python Packaging Summit

Tim Hopper — Mon, 18 May 2026 12:00:00 +0000

The 2026 Python Packaging Summit ran on Friday, May 15 in Long Beach. Bernát Gábor’s hour-by-hour recap is the long read; the pre-summit preview is the companion. Worth reading the whole thing if you ship or install Python packages.

The handbook-relevant headlines:

Wheel 2.0 was restructured into a small core PEP plus optional sub-PEPs, with Zstandard compression as the first sub-PEP. Roughly 25% smaller wheels on the top 1,000 PyPI projects. Broad adoption is years out.
Mike Fiedler laid out PyPI’s safety math: project creation up 3.1x and upload bytes up 3.5x since 2024, against one funded full-time safety engineer. Trusted publishing adoption climbed from ~10% to ~30%.
PEP 772 (Packaging Council) was accepted. First elections this fall, aligned with the PSF board cycle, with PSF voting membership required to nominate or be nominated.
PEP 803 defines abi3t, a stable ABI for free-threaded CPython. A single wheel can target both interpreters via a compound cp315-abi3.abi3t tag.
Mobile wheels work end to end (cibuildwheel supports Android and iOS) but adoption is small: 11 of the top 360 packages ship Android wheels, 9 ship iOS.

Learn more

Bernát Gábor’s full recap
HackMD collaborative summit notes
The 2026 Packaging Summit Returns to PyCon US (pre-summit preview)
PEP 777, Wheel 2.0
PEP 803, abi3t

Locking dependencies for PEP 723 single-file scripts in May 2026

Tim Hopper — Fri, 08 May 2026 09:00:00 -0400

PEP 723 plus uv made single-file Python scripts easy to share. Declare dependencies in a commented TOML block, drop the file in a gist, and uv run script.py builds an ephemeral environment and runs it without a project directory or activation step. Locking those dependencies so the script behaves the same six months from now is still awkward. The inline dependencies list pins the top-level requirements you specify and nothing else; the transitive graph gets re-resolved every time the script runs on a new machine.

Lightning Got Owned: When `import lightning` Steals Your Credentials

Tim Hopper — Thu, 30 Apr 2026 00:00:00 +0000

import lightning shows up at the top of millions of PyTorch training scripts. On April 30, 2026, that line was enough to ship a developer’s credentials to an attacker.

Two malicious versions of the lightning PyPI package, 2.6.2 and 2.6.3, were uploaded today. Lightning averages 311 thousand downloads a day, and any CI that ran uv sync --upgrade between the upload and the takedown pulled the bad wheel. Neither version corresponds to a GitHub release on Lightning-AI/pytorch-lightning; the latest tagged release there is still 2.6.1 from January 30. The bad code was uploaded directly to PyPI, which is the same pattern as the litellm compromise six weeks ago. Socket flagged both releases 18 minutes after upload, and PyPI has since quarantined the entire project.

Did pip 26 close the gap with uv?

Tim Hopper — Fri, 24 Apr 2026 09:00:00 -0400

pip 26.0 closed two of uv’s clearest feature gaps in January: PEP 723 script installs and a datetime-based package filter that mirrors uv’s --exclude-newer. The October 2025 Hacker News thread that kept circling back to “pip has quietly caught up” now reads less contrarian than it did at the time, and the OpenAI acquisition of Astral in March changes the “is this safe to depend on” calculus at the same time.

Review pip’s 2025 to 2026 releases

Four pip releases have landed since April 2025, and the first three narrowed gaps uv was best known for:

Astral told you how they secure uv. Here's what to keep.

Tim Hopper — Thu, 16 Apr 2026 00:00:00 +0000

Astral published a detailed writeup of how they secure the org that ships uv, Ruff, and ty. It’s a good post. It’s also, for most readers, the wrong post.

Most of what Astral describes is team-scale GitHub hygiene: org-wide branch protection rulesets, workflow audits with zizmor, action pinning with pinact, isolated GitHub Apps for privileged operations. If you run a project with outside contributors, read the whole thing. If you’re one person shipping a Python package, a lot of it is overkill for the threat model you actually face.

PyPI's Second Audit Found 14 Bugs. Two Remain.

Tim Hopper — Thu, 16 Apr 2026 00:00:00 +0000

PyPI completed its second external security audit today. Trail of Bits found 14 issues in the Warehouse codebase: 2 High, 1 Medium, 7 Low, 3 Informational, 0 Critical. Twelve were patched. Two were accepted as known gaps. The work was funded by the Sovereign Tech Agency, with remediation by PSF’s Mike Fiedler through Alpha-Omega support.

An audit of PyPI is an audit of the index infrastructure, not of the packages hosted on it. None of the findings describe malware in the wild. The patched bugs are the predictable part; the accepted ones are where the signal lives.

Your Python Wheels Still Target 2009 CPUs

Tim Hopper — Wed, 15 Apr 2026 00:00:00 +0000

Intel shipped AVX2 in 2013. AMD reached it with Excavator-era parts around 2015. Eleven years later, the default NumPy wheel pip downloads on an x86_64 Linux box is still compiled to run on processors from roughly 2003, the year AMD launched the Opteron and defined the AMD64 baseline. Every SIMD instruction that has shipped since is off-limits to the compiler that produced that wheel.

The reason is structural. A wheel filename encodes three pieces of compatibility metadata: Python version, ABI, and platform. “Platform” for mainstream Linux wheels is typically manylinux_2_17_x86_64, which says “works on any glibc 2.17+ x86-64 distro” and nothing about which CPU instruction sets the machine supports. When a project publishes one binary for all of those users, it has to target the lowest common denominator.

uv won developer hearts. Now it has to win READMEs.

Tim Hopper — Tue, 14 Apr 2026 09:00:00 -0400

uv ranked as the most admired technology in Stack Overflow’s 2025 Developer Survey at 74%. A recent analysis by Andrey Aleyan of the top 100,000 Python repositories on GitHub put uv adoption (measured by the presence of uv.lock) at roughly 10%. The gap between “developers love this” and “developers ship this” is wider than any tooling story in recent memory.

Aleyan’s diagnosis is that AI coding agents are the bottleneck: their training data is overwhelmingly pip install -r requirements.txt, so they emit pip install -r requirements.txt. That diagnosis is correct but incomplete. Adoption is bottlenecked by three reinforcing forces, and the AI-agent story is only one of them.

The Python Packaging Summit Returns to PyCon US

Tim Hopper — Thu, 09 Apr 2026 12:00:00 +0000

The Python Packaging Summit returns Friday, May 15, 2026 in Room 201A of the Long Beach Convention Center, running 1:45 to 5:45 PM on the Friday of PyCon US. Pradyun Gedam, C.A.M. Gerlach, and Jannis Leidel co-chair again. Attendance is capped and invite-only: submit the attendance form and topic-pitch form by April 30 (AoE). The schedule drops around May 4.

The summit puts the people who build uv, pip, Poetry, Hatch, conda, PyPI, and the major wheel-producing libraries in one room to argue through the year’s thorniest packaging questions. The notes from 2024 and 2025 are the best public window into where pyproject.toml, wheel tags, and lock files are headed.

LLM-Powered Copycats Are Flooding PyPI

Tim Hopper — Wed, 08 Apr 2026 00:00:00 +0000

A developer named Roman Dubrovin published repowise, a tool for generating structured wikis from codebases, as his first PyPI package. The next morning, he searched for it on PyPI and found three new packages he didn’t recognize: repowise-pro, repowise-enhanced, and repowise-next.

All three had been uploaded within a 90-minute window. All three carried the same description: “Codebase intelligence that thinks ahead — outperforms repowise on every dimension.”

They weren’t empty shells. Someone had forked Dubrovin’s AGPL-3.0 licensed source code, run it through an LLM to patch a couple of minor issues, and republished under new names without attribution or license compliance. A community member confirmed that all three packages traced back to the same person and the same GitHub repository.

In 2012, Guido Had No Idea NumPy Had Its Own Packaging System

Tim Hopper — Tue, 07 Apr 2026 00:00:00 +0000

In a recently resurfaced 2012 PyData panel discussion, Fernando Perez, Travis Oliphant, and David Cournapeau sat down with Guido van Rossum to discuss the scientific Python community’s needs. The conversation wandered through operator overloading (which eventually produced the @ matrix multiplication operator in Python 3.5) and import performance on supercomputers. The packaging segment is the one worth revisiting.

David Cournapeau, who maintained NumPy’s build infrastructure, explained that NumPy had written its own packaging layer on top of distutils that was “as much code as distutils itself.” NumPy had to override nearly every piece of distutils to handle Fortran compilers, C++ extensions, Cython, cross-platform compiler flags, and builds on exotic hardware like IBM Blue Gene supercomputers.

LiteLLM Got Owned, and Your Dependencies Might Be Next

Tim Hopper — Tue, 24 Mar 2026 00:00:00 +0000

Earlier today, someone published malicious versions of litellm (versions 1.82.7 and 1.82.8) to PyPI. No corresponding release appeared on GitHub. The package was uploaded directly to PyPI, bypassing the normal release process, which points to a compromised maintainer account or token.

What the malware did

The payload was a .pth file named litellm_init.pth. Python executes .pth files automatically on interpreter startup, so the malware ran without any user interaction once the package was installed.

How Python's RFC Process Paved the Way for uv, Ruff, and Ty

Tim Hopper — Fri, 01 Aug 2025 15:22:00 -0400

Astral, an independent startup, has taken the Python world by storm over the last few years with three fast, robust Python developer tools:

ruff (linter and formatter)
uv (packaging and project management)
ty (static type checker, still under development)

These tools came from the mind of Charlie Marsh, who is neither a Python core developer nor directed by the Python Steering Council. While being independently developed, these tools work seamlessly within the established Python ecosystem. This success stems partly from Astral’s attention to guidelines established by the Python Enhancement Proposal (PEP) process over the last twenty-five years.

Why isn't Python packaging part of core development?

Tim Hopper — Wed, 16 Jul 2025 10:51:00 -0400

In a video interview with bitecode.dev, Python core developer Brett Cannon explains why packaging was never part of core development. The answer is disarmingly simple: the people in charge weren’t interested.

Basically, they’re separate because Guido doesn’t care about packaging. That’s really what it comes down to. When packaging started to become a thing, we just didn’t have any interest in it, and so it never became a core dev concern. It just never came up—it was just not our thing. So the community in various ways stepped up to fill that void.

The uv build backend is now stable

Tim Hopper — Thu, 03 Jul 2025 01:29:29 +0000

For about a year, uv has had a uv build command for generating distributable wheels and source distributions on pypi and elsewhere.

However, uv has relied on other tools for the build backend, i.e. the actual piece constructing the wheel or sdist as defined by PEP 517. By default, uv uses hatchling as the build backend.

As of this week, the uv team has now declared the uv build backend as stable and, most notably, really, really fast. Charlie Marsh’s benchmarks suggest that it’s 10 to 35 times faster than flit, hatchling, and setuptools. While I’ve never really needed my package builds to be faster, I’ve learned that faster tools often enable new things I didn’t imagine possible; I’m interested to see what those might be here.

Setuptools 78.0.1 breaking package installation

Tim Hopper — Mon, 24 Mar 2025 13:54:00 +0000

Update: Setuptools released version 78.0.2 postponing this breaking change.

A recent update to setuptools (version 78.0.1) is breaking installations of many packages, particularly older or unmaintained ones that use dash-separated keys instead of the now-required underscore format.

Why Doesn't the Authoritative Python Packaging Guide Mention the Best Thing that's Happened to Python Packaging?

Tim Hopper — Thu, 27 Feb 2025 14:56:00 +0000

Despite uv’s meteoric rise and widespread adoption in the Python community over the last year, the excellent and official Python Packaging User Guide (PPUG) at packaging.python.org makes no mention of it. Understanding why this is requires some background knowledge and unveils understanding of the modern Python developer tooling ecosystem.

uv’s Rise

Since its introduction in early 2024, uv has rapidly gained traction as a high-performance alternative to existing Python tooling. uv delivers 10-100x faster package operations than traditional tools while consolidating functionality previously spread across multiple utilities (pip, pip-tools, virtualenv, pyenv, and more). Its performance advantages, cross-platform support, and unified approach have made it increasingly popular among Python developers.

Poetry's Move Toward Python Standards

Tim Hopper — Fri, 21 Feb 2025 16:08:00 +0000

This is an excerpt from the forthcoming Python Developer’s Tool Handbook. The handbook provides comprehensive guidance on Python tooling and best practices for modern Python development.

While modern Python build tools like uv, Hatch, PDM, and Flit embraced PEP 621’s standardized project metadata from their inception, Poetry - one of the most widely used packaging tools - maintained its own configuration format in tool.poetry until version 2.0. This delay reflected both Poetry’s established user base and its richer feature set beyond standard packaging needs.

Why Use uv Projects Instead of requirements.txt?

Tim Hopper — Wed, 19 Feb 2025 09:17:00 +0000

This is an excerpt from the forthcoming Python Developer’s Tool Handbook. The handbook provides comprehensive guidance on Python tooling and best practices for modern Python development.

The Python ecosystem offers two main approaches to managing project dependencies: the traditional requirements.txt file and the newer pyproject.toml standard. Understanding the strengths and limitations of each helps inform better choices for Python development.

Effective Python Developer Tooling in December 2024

Tim Hopper — Fri, 20 Dec 2024 19:25:00 +0000

I have been writing Python for 14 years next month. When I started, people were still using easy_install to install egg-based packages for Python 2.7 and nobody had heard about Conda yet, much less uv. The Python tool ecosystem has changed since. Many people are confused by the fragmentation in the ecosystem, but we have better tooling for Python today than we’ve ever had before.

A friend recently invited me to give a talk to his team about Python tooling. In the presentation, I shared some principles of Python tooling and developer efficiency, some anti-patterns I’ve observed, recommended practices, and an opinionated list of tools I like in December 2024. What follows is a summary of that talk.

Require pip to install packages in virtual environment

Tim Hopper — Mon, 04 Mar 2024 15:34:08 +0000

A frequently heard piece of advice in improving Python development practice is using virtual environments to install dependencies. Virtual environments isolate your dependencies per project to protect you from annoying version conflicts.

You can restrict pip to only install in virtual environments by running

pip config set global.require-virtualenv true

This updates your global pip config file.

Pip and Poetry and Hatch, Oh My!

Tim Hopper — Wed, 14 Feb 2024 20:51:18 +0000

Modern Python developers have a plethora of tooling available to help the development process. When I started with Python in 2011, packaging was done with setuptools (or its predecessor distutils), and virtual environments were created with the virtualenv library.

Now developers can (have to?) choose between a breadth of packaging tools (e.g., setuptools, Flit, Poetry, PDM, Hatch). Some of these tools manage virtual environments while others require the developer to do this themself. Every developer managing virtual environments has had to figure out the difference between venv and virtualenv–not to mention wondering how they differ from Conda environments.

Scientific Python Library Development Guide

Tim Hopper — Mon, 12 Feb 2024 00:00:00 +0000

Along with the Python Packaging User Guide, another excellent resource for learning about Python development practice is the Scientific Python Library Development Guide, a “guide is maintained by the scientific Python community for the benefit of fellow scientists and research software engineers”.

I especially like their topical guides on topics like packaging and getting started with Github Actions.

Python Packaging Tool Examples

Tim Hopper — Tue, 06 Feb 2024 00:00:00 +0000

In the last few years, Python packaging has seen a lot of change. Instead of every project using setuptools/setup.py, there are now many tools to choose from when building and distributing Python packages. This can be overwhelming for new and experienced developers alike.

My goal with the Python Developer Tooling Handbook is to help you make informed choices to make your Python development easier and more productive.

As I’ve tried to learn the ins-and-outs of these tools, I created a series of example repositories showing how to use each of the major packaging tools. I hope these examples will be helpful to you as you learn about Python packaging.

Introduction to Rye

Tim Hopper — Sat, 03 Feb 2024 00:00:00 +0000

Note

Rye’s author Armin Ronacher now recommends uv for new projects. Rye continues as a maintained project, but uv has become the primary focus for modern Python tooling. See uv’s documentation for migration guidance.

Python Packaging User Guide

Tim Hopper — Sat, 03 Feb 2024 00:00:00 +0000

The Python Packaging Authority produces an excellent resource called the Python Packaging User Guide, “a collection of tutorials and references to help you distribute and install Python packages with modern tools”.

If you’re feeling frustrated by Python packaging, I highly recommend reading through this guide and considering it’s suggestions.

My forthcoming Python Developer Tooling Handbook will cover much of the same material, but it intended as a complement to the Python Packaging User Guide, not a replacement.