In March 2026, the LiteLLM package was compromised on PyPI through a hijacked CI/CD pipeline, silently exfiltrating credentials and secrets. Months earlier, fake DeepSeek packages targeted ML engineers with infostealers. Standard Python tooling resolves and builds packages individually with no unified view of the full dependency tree, making it hard to audit what was built, from where, and in what order.

Fromager solves this by capturing the entire dependency tree as data. A bootstrap step recursively resolves all dependencies and outputs the full graph and build order as plain JSON artifacts you can review, diff, and version-control before any compilation happens. From that plan, every package is rebuilt from source in the correct order, optionally with network isolation to constrain what build scripts can reach. The result is a fully visible, reproducible supply chain.

Fromager builds packages as collections, the full dependency tree is compiled together, so packages linked against each other stay ABI-compatible. This matters for stacks like PyTorch and vLLM where mismatches between CUDA or ROCm binaries cause silent failures.

A plugin and override system lets you customize each build stage (download, unpack, patch, build) per package. One upstream recipe can produce builds for different hardware targets while keeping the rest of the configuration shared.

We'll cover what we've learned building 1000+ packages for production AI workloads: dependency patterns specific to AI stacks, where source builds break at scale, and why building as collections is necessary for ABI correctness across accelerators.

This talk is for engineers who build, deploy, or audit Python environments for production AI workloads, especially those dealing with hardware-specific builds, reproducibility requirements, or supply chain compliance. Attendees will leave with an understanding of how to evaluate their own Python supply chains and the tools to start building from source themselves