El concepto de compilaciones reproducibles (reproducible builds) en el ecosistema de empaquetado de Python aún no tiene un camino definido dentro de PyPI. La idea central es que un tercero independiente pueda verificar que los bits contenidos en una distribución (ya sea un sdist o una rueda/wheel) coinciden con lo que se esperaría obtener a partir del código fuente publicado, lo que permite detectar manipulaciones durante el proceso de compilación. Aunque el término "build" puede sugerir que las ruedas de Python puro están a salvo, lo cierto es que también pasan por un backend de compilación que podría verse comprometido, como ilustra el caso de SolarWinds.
Para que las compilaciones reproducibles sean viables en el ecosistema Python, el artículo identifica tres piezas fundamentales. En primer lugar, es necesario registrar de dónde procede el código fuente: ni los sdists ni las ruedas almacenan hoy esa información, aunque pip sí la guarda en el archivo direct_url.json al instalar desde un repositorio o archivo. En segundo lugar, hay que dejar constancia de todo el software empleado en la compilación; las ruedas ya admiten SBOMs (listas de materiales de software) gracias a la PEP 770, pero los sdists carecen de un mecanismo equivalente y habría que pensar en un formato sdist v2 con metadatos más estructurados. En tercer lugar, el propio backend de compilación debería anotar qué tiene instalado en su entorno, lo que permitiría registrar todos los componentes sin trabajo adicional por parte de quien publica la distribución, aunque implicaría cambios en pip.
El autor también propone que PyPI muestre públicamente qué distribuciones han sido reproducidas con éxito por verificadores de confianza, e incluso que esta información aparezca en el API de índices para que los instaladores prioricen paquetes verificados. Todo esto se plantea como una funcionalidad opcional y ventajosa —equivalente al nivel 1 de SLSA—, nunca como un requisito que penalice a quienes no la adopten.