InsightSoftwareConsortium / InsightSoftwareConsortium/ITK
Stale <Module>Config.py in build tree breaks itk.force_load() and 11 Python tests
- Dominant language
- C++
- Stars
- 1.7k
- Forks
- 748
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 64
Description
A stale `Config.py` left in a build tree makes `itk.force_load()` — and therefore ~11 Python tests — fail with an unhandled `FileNotFoundError`, even though the module in question is disabled and correctly not built.
## Symptom
```
FileNotFoundError: [Errno 2] No such file or directory:
'.../Wrapping/Generators/Python/itk/support/../MontagePython.py'
```
Raised from `itk/support/base.py` → `loader.load(swig_module_name)` while walking the module list.
## Tests affected
All fail from the same root cause:
```
PythonFindEmptyClasses PythonVerifyTTypeAPIConsistency
PythonGetNameOfClass PythonTypeTest
PythonTiming PythonTemplateTest
PythonBuildOptions PythonExtrasTest
PythonVerifyGetOutputAPIConsistency
PythonFFTObjectFactoryTest PythonLazyLoadingImage
```
They share the property of loading all modules (`itk.force_load()`) or exercising lazy loading, so any one unloadable entry takes them all down.
## Reproducer
1. Configure a Python-wrapping build with a module enabled (here `Module_Montage=ON`).
2. Build, so `itk/Configuration/MontageConfig.py` is generated.
3. Set the module `OFF` (or drop the remote module — Montage has since been ingested into ITK proper) and rebuild.
4. `MontageConfig.py` **survives** in the build tree, but `MontagePython.py` is never generated.
5. `itk.force_load()` now raises.
Confirmed by moving the stale `MontageConfig.py` aside: all 11 tests pass immediately, no rebuild required.
## Why this is worth fixing
The failure mode is badly misleading. It presents as 11 unrelated Python test failures spread across FFT, type-consistency and lazy-loading, with no mention of the disabled module in the test names, and it persists across rebuilds. Bisecting toward a stale generated file is slow, and a developer is likely to suspect their own change first.
The `ITKFFTImageFilterInit` label on the failures is especially misdirecting, since FFT is not involved in the root cause.
## Suggested fixes
Either would resolve it; the first is the more complete:
1. **Remove stale configuration at build time.** When a module is not enabled, ensure any previously generated `Config.py` is deleted from `itk/Configuration/` rather than left behind.
2. **Fail soft in the loader.** In `itk/support/base.py`, treat a config whose corresponding `Python.py` is missing as a skippable entry — warn and continue, rather than propagating `FileNotFoundError`. This also protects against partially-built trees.
Option 2 alone would keep a stale tree usable; option 1 alone keeps trees clean going forward but does not help existing ones. Doing both seems reasonable.
## Environment
- ITK `main` @ `3ae346c2409`
- Linux, `ITK_WRAP_PYTHON=ON`, `CMAKE_BUILD_TYPE=Release`
- `Module_Montage:BOOL=OFF` in `CMakeCache.txt`, `MontageConfig.py` still present in the build tree
Contributor guide
Research direction
Start in itk/support/base.py at loader.load(swig_module_name), then trace the build-generation path that leaves Config.py in itk/Configuration/. Reproduce with Module_Montage toggled off and run itk.force_load() or the listed Python tests. Done means stale disabled-module configuration no longer breaks loading, and the affected tests pass.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cmake, python
- Domain
- build-system, testing
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100