InsightSoftwareConsortium / InsightSoftwareConsortium/ITK

Stale <Module>Config.py in build tree breaks itk.force_load() and 11 Python tests

Open
#6,708 1 comment 1 reaction 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.