Uploaded August 2026 | Updated September 2026, 2 weeks ago
[EuroPython 2026 - S2 on 2026-07-16]
🎤 *Binary Dependencies: Identifying the Hidden Packages We All Depend On by Vlad-Stefan Harbuz*
🔗 https://ep2026.europython.eu/session/binary-dependencies-identifying-the-hidden-packages-we-all-depend-on
📝 Abstract:
Package manifests like *pyproject.toml* record source-level dependencies: _pandas_ depends on _numpy's_ code. The story is different for binary dependencies, which exist whenever compiled code, like C code, is called from Python. _numpy_ depends on _OpenBLAS's_ binaries, but this dependency relationship is not recorded anywhere. This makes _OpenBLAS_ a _phantom (endorlabs.com/learn/dependency-resolution-in-python-beware-the-phantom-dependency) binary dependency._
Phantom dependencies are therefore hidden from programmers and researchers, which is bad for at least two reasons.
First, security. If one of your binary dependencies has a vulnerability, this means your project is probably also vulnerable — but you won't reliably find out about this, since your dependency is invisible.
Secondly, sustainability. If we can't keep track of our binary dependencies, we can't keep track of their maintainers either, which means we can't credit and financially support (opensourcepledge.com/) them. This can lead to maintainer burnout (opensourcepledge.com/blog/burnout-in-open-source-a-structural-problem-we-can-fix-together/) which has already created serious supply chain issues.
Python is not only tremendously popular, but also valued for its ability to easily interface with compiled libraries. According to my research, around 20% of Python packages have binary dependencies.
This means that the problem of phantom binary dependencies is widespread, and puts the public at risk of harm, eg if critical infrastructure like hospitals or transportation is compromised by exploiting the aforementioned weaknesses.
I aim to describe how the problem of phantom binary dependencies can be fixed within the Python ecosystem, and demo some of my preliminary work.
First, binary dependencies must be identified. Tools like _auditwheel (github.com/pypa/auditwheel/)_ and _elfdeps (github.com/python-wheel-build/elfdeps/)_ are able to identify a project's required dynamic libraries (https://vlad.website/how-binary-dependencies-work/ ). If we create better APIs for these tools, and integrate them with package managers such as _pip_ and _uv,_ we can give developers and researchers visibility into binary dependencies, dispelling the phantom.
Beyond this, standards like PEP 725 (peps.python.org/pep-0725/) , PEP 770 (peps.python.org/pep-0770/) and PEP 804 (peps.python.org/pep-0804/) specify how we might record binary dependency relationships in an easily accessible way. I'll explain how we can build on these standards to create tools that will allow users and researchers to explore binary dependencies and identify security issues by default.
Lastly, I want to talk about the road towards the ultimate aim of having binary dependencies be managed not by Python package managers, but by system package managers, as they should be. This will require interoperation between package managers, and I'll explain how this might work.
---
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: creativecommons.org/licenses/by-nc-sa/4.0
[EuroPython 2026 - S2 on 2026-07-16]
🎤 *Binary Dependencies: Identifying the Hidden Packages We All Depend On by Vlad-Stefan Harbuz*
🔗 https://ep2026.europython.eu/session/binary-dependencies-identifying-the-hidden-packages-we-all-depend-on
📝 Abstract:
Package manifests like *pyproject.toml* record source-level dependencies: _pandas_ depends on _numpy's_ code. The story is different for binary dependencies, which exist whenever compiled code, like C code, is called from Python. _numpy_ depends on _OpenBLAS's_ binaries, but this dependency relationship is not recorded anywhere. This makes _OpenBLAS_ a _phantom (endorlabs.com/learn/dependency-resolution-in-python-beware-the-phantom-dependency) binary dependency._
Phantom dependencies are therefore hidden from programmers and researchers, which is bad for at least two reasons.
First, security. If one of your binary dependencies has a vulnerability, this means your project is probably also vulnerable — but you won't reliably find out about this, since your dependency is invisible.
Secondly, sustainability. If we can't keep track of our binary dependencies, we can't keep track of their maintainers either, which means we can't credit and financially support (opensourcepledge.com/) them. This can lead to maintainer burnout (opensourcepledge.com/blog/burnout-in-open-source-a-structural-problem-we-can-fix-together/) which has already created serious supply chain issues.
Python is not only tremendously popular, but also valued for its ability to easily interface with compiled libraries. According to my research, around 20% of Python packages have binary dependencies.
This means that the problem of phantom binary dependencies is widespread, and puts the public at risk of harm, eg if critical infrastructure like hospitals or transportation is compromised by exploiting the aforementioned weaknesses.
I aim to describe how the problem of phantom binary dependencies can be fixed within the Python ecosystem, and demo some of my preliminary work.
First, binary dependencies must be identified. Tools like _auditwheel (github.com/pypa/auditwheel/)_ and _elfdeps (github.com/python-wheel-build/elfdeps/)_ are able to identify a project's required dynamic libraries (https://vlad.website/how-binary-dependencies-work/ ). If we create better APIs for these tools, and integrate them with package managers such as _pip_ and _uv,_ we can give developers and researchers visibility into binary dependencies, dispelling the phantom.
Beyond this, standards like PEP 725 (peps.python.org/pep-0725/) , PEP 770 (peps.python.org/pep-0770/) and PEP 804 (peps.python.org/pep-0804/) specify how we might record binary dependency relationships in an easily accessible way. I'll explain how we can build on these standards to create tools that will allow users and researchers to explore binary dependencies and identify security issues by default.
Lastly, I want to talk about the road towards the ultimate aim of having binary dependencies be managed not by Python package managers, but by system package managers, as they should be. This will require interoperation between package managers, and I'll explain how this might work.
---
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: creativecommons.org/licenses/by-nc-sa/4.0
