quantecon-build container: unpinned scipy/numpy causes CellExecutionError in un_insure.md

[mmcky]

Summary

The ghcr.io/quantecon/quantecon-build:latest container has unpinned numpy and scipy in its environment.yml, which resolves to the latest versions at image build time. A recent scipy update (likely 1.15+) introduced a breaking change that causes un_insure.md to fail with a TypeError during execution.

Affected Repositories

• lecture-dp — CI uses quantecon-build container; builds have been failing since ~March 12-16, 2026
  • Failed scheduled build on main (March 23)
  • Failed PR build #6
• lecture-python-advanced.myst — Source repo for un_insure.md; builds fine because it uses anaconda=2025.12 metapackage (which pins scipy/numpy to compatible versions)

Error

The failure occurs in un_insure.md Cell 7, when sp.optimize.brentq calls sp.optimize.fsolve internally:

TypeError: only 0-dimensional arrays can be converted to Python scalars

File scipy/optimize/_minpack_py.py, line 235, in _root_hybr
    x0 = asarray(x0).flatten()

Full traceback is in the execution-reports-html artifact.

Root Cause

The container environment.yml specifies:

- numpy
- scipy

These resolve to whatever is latest at build time. The source repo (lecture-python-advanced.myst) avoids this by pinning anaconda=2025.12, which locks scipy/numpy to a known-compatible set.

The specific breakage is in how newer scipy handles the x0 argument to fsolve — the code passes a scalar (15000) that previously worked but now fails due to stricter array conversion in numpy 2.x / scipy 1.15+.

Possible Fixes

1. Pin scipy/numpy versions in the container environment.yml (e.g., scipy<1.15 or match anaconda=2025.12)
2. Add anaconda=2025.12 to the container environment to match source repos
3. Fix the lecture code to pass np.array([15000]) instead of 15000 to fsolve (but this should be done upstream in lecture-python-advanced.myst)

How to Verify

The last successful scheduled build on lecture-dp main was March 9. The first failure was March 16. Checking which container image version was in use for each would identify the exact scipy version that broke things.