OSS + ELC EU 2026

When you run pip install numpy, pip downloads a pre-built binary someone else compiled. For most developers that's fine, but in regulated environments or anywhere supply chain integrity matters, it's a gap one that incidents like the LiteLLM PyPI compromise and fake DeepSeek packages have made harder to ignore.

There's a bootstrapping problem too: building numpy needs setuptools, and building setuptools needs… setuptools. Every existing tool pip, uv, conda breaks this cycle by quietly downloading pre-built binaries. None give you a unified view of the full dependency tree, making it hard to audit what was built, from where, and in what order.

This talk walks through an unsolved problem in Python packaging bootstrapping entire dependency trees from source and how Fromager tackles it using PEP 517. We'll cover:

1. Why pip install --no-binary :all: doesn't get you to "built from source"
2. Where pip, Nix, Spack, and Bazel each fall short
3. The two-stage discover/build split and the JSON artifacts it produces for auditing
4. Why building packages as collections keeps them ABI-compatible critical for stacks like PyTorch with CUDA/ROCm native code