[hahn-kev-bot]

---

AI summary

ubuntu-latest is now Ubuntu 26.04 (Python 3.14), and the Mercurial 6.5 bundled with the pinned Chorus client dies on startup there with partially initialized module 'threading' has no attribute 'RLock'. So the pinned leg failed on master (run) and the image with #27 wasn't pushed.

The cause isn't the Python version as such: newer CPython's importlib.util.LazyLoader imports threading itself, which loops when hg 6.5's demandimport lazy-loads threading. Ubuntu 24.04's Python 3.12.3 predates that change, which is why it used to pass; a first attempt with setup-python 3.12 (3.12.16) failed the same way.

Old clients in the field still use hg 6.5, so this keeps the leg on ubuntu-latest and sets HGDEMANDIMPORT=disable for the pinned leg only. The bundle's module policy is allow, so on 3.14 it falls back to pure Python. The latest leg (hg 7.2) keeps demandimport on; the hg3 leg runs on Python 2.7.

Checked locally: the bundle's Linux hg version reproduces the error on Python 3.14 and starts with HGDEMANDIMPORT=disable.

LexBox hit the same thing in sillsdev/languageforge-lexbox#2861 (it pinned its hg 6 legs to ubuntu-24.04 instead).

Test plan

• The "Integration tests (pinned Chorus)" leg passes on this PR

🤖 Generated with Claude Code

[rmunn]

This is a good plan. The only difference that HGDEMANDIMPORT=disable makes is to load Python modules eagerly when the import command is reached. (Mercurial's default behavior is to turn import statements into lazy-loading objects that only import their module when someone tries to access the module's contents). In theory this could change behavior if a module has a bug, e.g. an exception could be thrown that wouldn't have been thrown by the default Mercurial behavior. But that's not the case here, or we would have seen test failures. And setting HGDEMANDIMPORT=disable does not change what Mercurial sends or reads on the wire, how it handles merge logic, and so on.

So this is the simplest change we can make that will continue to work.