Summary
The Dockerfile is stale and, as written, almost certainly cannot build end-to-end on Linux today. It was last "refreshed" cosmetically in dc6ad10 (Python 3.12 + BioNetGen 2.9.3), but that same commit made bngsim a hard dependency — which the container has no way to satisfy on Linux. It needs a real overhaul, not a touch-up. It is also not built or tested anywhere in CI, so it can rot silently.
How the Dockerfile works today
Three-stage build (Dockerfile):
bionetgen-build — clones BioNetGen from GitHub at a pinned tag (BioNetGen-2.9.3) and compiles it from source (make_dist.pl --build).pybnf-build — builds the PyBNF wheel with pip wheel --no-deps.- runtime (
python:3.12-slim) — installs libgomp1 + perl, copies in the compiled BioNetGen and the wheel, then pip installs the wheel and sets BNGPATH/PATH.
Problems
1. Build-breaking: the runtime pip install requires bngsim, which has no Linux wheel
Dockerfile:72 runs pip install /tmp/wheels/*.whl without --no-deps, so pip resolves PyBNF's full dependency set — including the hard requirement bngsim>=0.5.0,<1 added in dc6ad10 ("Modernize packaging and require BNGsim"). bngsim is a private, macOS-only wheel with no public Linux build (see the notes in .github/workflows/integration.yml and .github/actions/setup-pybnf/action.yml: the hosted CI deliberately installs PyBNF without bngsim via --no-deps, "until bngsim ships Linux wheels"). The --build-arg PIP_EXTRA_INDEX_URL escape hatch only helps if such an index with a Linux bngsim wheel exists — it does not today.
Result: the runtime stage's pip install should fail to resolve bngsim on Linux.
2. Conceptual mismatch: the image bundles only the legacy BNG2.pl backend
The container compiles and ships legacy BioNetGen (BNG2.pl), but modern PyBNF centers on the bngsim simulation backend. Even if the install succeeded, the container would only offer the legacy backend. We should decide deliberately what a PyBNF container is for: a BNG2.pl-only legacy image, or a real bngsim image once Linux wheels exist.
3. Staleness
- Pinned to Python 3.12; PyBNF now supports 3.13.
- Pinned to BioNetGen 2.9.3 (fine to pin, but should be reviewed alongside the rest).
- Not built or tested in CI → no guard against silent rot.
Suggested directions (pick one for the backend story)
- A — BNG2.pl-only legacy image (works today): mirror the CI install —
pip install --no-deps the wheel, then install the public runtime deps explicitly (the same list as .github/actions/setup-pybnf/action.yml), omitting bngsim. Document the image as the legacy BNG2.pl backend.
- B — bngsim image (blocked): wait on / depend on bngsim Linux wheels, then make bngsim the backend and drop the from-source BNG2.pl build.
Acceptance criteria
References
Dockerfile (esp. line 72, the runtime pip install)- dc6ad10 "Modernize packaging and require BNGsim" — made
bngsim a hard dep and refreshed the Dockerfile
.github/actions/setup-pybnf/action.yml — the working bngsim-less install pattern to mirror.github/workflows/integration.yml — "until bngsim ships Linux wheels"
Summary
The
Dockerfileis stale and, as written, almost certainly cannot build end-to-end on Linux today. It was last "refreshed" cosmetically in dc6ad10 (Python 3.12 + BioNetGen 2.9.3), but that same commit madebngsima hard dependency — which the container has no way to satisfy on Linux. It needs a real overhaul, not a touch-up. It is also not built or tested anywhere in CI, so it can rot silently.How the Dockerfile works today
Three-stage build (
Dockerfile):bionetgen-build— clones BioNetGen from GitHub at a pinned tag (BioNetGen-2.9.3) and compiles it from source (make_dist.pl --build).pybnf-build— builds the PyBNF wheel withpip wheel --no-deps.python:3.12-slim) — installslibgomp1+perl, copies in the compiled BioNetGen and the wheel, thenpip installs the wheel and setsBNGPATH/PATH.Problems
1. Build-breaking: the runtime
pip installrequiresbngsim, which has no Linux wheelDockerfile:72runspip install /tmp/wheels/*.whlwithout--no-deps, so pip resolves PyBNF's full dependency set — including the hard requirementbngsim>=0.5.0,<1added in dc6ad10 ("Modernize packaging and require BNGsim").bngsimis a private, macOS-only wheel with no public Linux build (see the notes in.github/workflows/integration.ymland.github/actions/setup-pybnf/action.yml: the hosted CI deliberately installs PyBNF without bngsim via--no-deps, "until bngsim ships Linux wheels"). The--build-arg PIP_EXTRA_INDEX_URLescape hatch only helps if such an index with a Linux bngsim wheel exists — it does not today.Result: the runtime stage's
pip installshould fail to resolvebngsimon Linux.2. Conceptual mismatch: the image bundles only the legacy BNG2.pl backend
The container compiles and ships legacy BioNetGen (
BNG2.pl), but modern PyBNF centers on thebngsimsimulation backend. Even if the install succeeded, the container would only offer the legacy backend. We should decide deliberately what a PyBNF container is for: a BNG2.pl-only legacy image, or a real bngsim image once Linux wheels exist.3. Staleness
Suggested directions (pick one for the backend story)
pip install --no-depsthe wheel, then install the public runtime deps explicitly (the same list as.github/actions/setup-pybnf/action.yml), omitting bngsim. Document the image as the legacy BNG2.pl backend.Acceptance criteria
docker buildsucceeds end-to-end on Linux (no private-index dependency on a nonexistent bngsim Linux wheel).References
Dockerfile(esp. line 72, the runtimepip install)bngsima hard dep and refreshed the Dockerfile.github/actions/setup-pybnf/action.yml— the working bngsim-less install pattern to mirror.github/workflows/integration.yml— "until bngsim ships Linux wheels"