Reorganize RemoteModules for reduced maintenance burden

Engineering
, ,
1

RFC: Consolidating remote modules into hierarchical category repos

Tracking issue: ENH: Consolidate remote modules into hierarchical category repos · Issue #6060 · InsightSoftwareConsortium/ITK · GitHub

ITK currently maintains ~60 separate remote module repositories. Each has its own git repo, CI configuration, Python packaging, and boilerplate. This creates significant maintenance overhead:

  • ~10,600 lines of duplicated boilerplate across modules
  • CI workflow versions fragmented across 10 different action tags
  • A single CI infrastructure update requires 15+ coordinated PRs
  • Every new filter requires creating an entirely new repository

This came up in the SSIM filter PR #6034 discussion where @blowekamp, @dzenanz, and I agreed that consolidation is needed and that the 6.0 beta phase is the right time.

The idea

Mirror ITK’s internal Modules/[Core|IO|Filtering|...] group hierarchy in Remote modules. Group ~50 modules into 7 category repos by domain, bringing the total from ~60 repos down to under 10 ISC-managed repos.

Proposed categories: IO, Filtering, Mesh, Analysis, Registration, Microscopy, Kitware

New CMake sub-group options (ITKGroup_Remote_IO, ITKGroup_Remote_Filtering, etc.) control which category repos are fetched. All OFF by default. Individual Module_<name> toggles still work within an enabled sub-group.

New modules (like SSIM) would be added as a subdirectory PR to the appropriate category repo – no new git repo needed.

Key design decisions we need input on

  1. Category groupings – are IO/Filtering/Mesh/Analysis/Registration/Microscopy/Kitware the right buckets?
  2. Domain vs. maintainer – grouping is by domain, not who currently maintains it. Some “external” repos are artifacts of the old one-module-per-repo requirement. Maintainers may prefer to be part of a larger codebase. Each placement should be discussed.
  3. Microscopy scope – IOOpenSlide is the only current candidate. Enough to justify a separate repo, or too small?
  4. KitwareMedical modules – Kitware-managed repo, or merge into ISC categories by domain?
  5. PyPI packaging – per-category wheels (itk-remote-io) replacing ~50 individual itk-<name> packages. Acceptable?
  6. Large independents – RTK, TubeTK, WebAssemblyInterface likely stay independent. Others?

Full proposal with module assignments, CMake mechanism details, and implementation phases is in the tracking issue #6060. Please comment there for decisions that need to be recorded; use this thread for broader discussion.

1 Like