Skip to content

ENH: Add Modules/Beta/ container (infra-only for stacked beta-module ingests) #6085

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
hjmjohnson wants to merge 1 commit into from
Closed

ENH: Add Modules/Beta/ container (infra-only for stacked beta-module ingests) #6085

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions CMakeLists.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -741,6 +741,12 @@ endif()
# dependencies.
add_subdirectory(Modules/Remote)

# In-tree beta modules (formerly remote fetches, now grafted inline).
# Loads provenance manifests (Modules/Beta/*.beta.cmake) and is a no-op
# at build time; the actual modules under Modules/Beta/<Name>/ are
# discovered via the normal itk-module.cmake DAG scan below.
add_subdirectory(Modules/Beta)

# Enable modules according to user inputs and the module dependency DAG.
include(ITKModuleEnablement)

Expand Down
32 changes: 32 additions & 0 deletions Modules/Beta/CMakeLists.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
# Modules/Beta/
#
# In-tree home for modules that were formerly configure-time remote
# fetches (Modules/Remote/*.remote.cmake). Each module lives at
# Modules/Beta/<Name>/ with its own itk-module.cmake and is discovered

@hjmjohnson hjmjohnson Apr 19, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would welcome suggestions for the naming of this new subdirectory. I chose "Beta," but I don't have a strong affinity for it. Perhaps "Community", "PreRelease", "Contributed", .... ?

I like the overall simplicity of this scheme. It's extensible, provides containment for items we don't yet want to put into the primary core, and provides historical context as we move some elements into the core.

@thewtex thewtex Apr 20, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are they not added to their appropriate group / module according to their topic? We want to make modules simpler and more maintainable. And easier for libraries clients to use and find content.

@hjmjohnson hjmjohnson Apr 20, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thewtex

TLDR; Shortest path to reduced maintenance burden.

======

I was trying to keep the scope of this initial step small. The primary concern at the moment was reducing the maintainer burden by moving all code for modules primarily maintained by the core ITK developers into ITK. Thus, greatly reduces the number of repositories that need to be touched for every style, code, or CI change.

Using this beta directory adjacent to the review directory allows for the minimum amount of infrastructure change to achieve the goal of reducing maintenance burden.

Moving them from Remote or Beta to a location where clients can more easily find their content will likely involve extensive community discussions about each module: about testing code coverage, code quality, whether they have broad community appeal, ITK style conformance, and other concerns that will likely take a longer time frame to resolve per module.

This step is nearly all mechanical. I was hoping that this would allow 1/2 - 3/4 of the current remote modules to be sucked into ITK's primary repo quickly. The build behavior does not change, and it should be backward compatible with external tools that currently enable a subset of Remote modules.

@hjmjohnson hjmjohnson Apr 20, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thewtex If you think the correct path is to move directly from remote modules to direct ITK integration, would you recommend a single PR per remote module, 1 per day over the next month or two?

I'll make a trial remote module -> Direct ITK inclusion draft PR for Cuberille as a discussion point to contrast with the proposed method here.

@thewtex thewtex Apr 20, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The primary concern at the moment was reducing the maintainer burden by moving all code for modules primarily maintained by the core ITK developers into ITK.

I agree with this goal.

Using this beta directory adjacent to the review directory allows for the minimum amount of infrastructure change to achieve the goal of reducing maintenance burden.

This duplicates code, in an unstable location, and at location that is not logically connected with existing groups and modules. This is increasing maintenance burden.

Many of the remote modules have not changed for years, have at least decent test coverage, and are not going to change. Some are easier to identify than others on which Group and Module (or a new module) they belong in. Some are trivial to locate. I do not agree that another beta group is better than putting it in the appropriate location.

@hjmjohnson I agree with you that a single PR per remote module is what is going to improve maintenance burden. It does not have to be all of them -- just the most obvious ones will make a difference on the maintenance burden and beneficial impact on the community. Then mark the remote module repository Archived on GitHub.

I'll make a trial remote module -> Direct ITK inclusion draft PR for Cuberille as a discussion point to contrast with the proposed method here.

Thank you!

# automatically by the normal ITK module DAG scan (see
# CMake/ITKModuleEnablement.cmake).
#
# Alongside each ingested module, an optional manifest
# Modules/Beta/<Name>.beta.cmake records upstream provenance
# (UPSTREAM_URL, UPSTREAM_SHA at last ingest, INGEST_DATE, license,
# compliance level). The manifest files are inert at build time --
# they are passive metadata consumed by tooling and human readers.

# itk_beta_module_manifest() is a no-op that makes the *.beta.cmake
# files valid CMake so they can be include()-d by tooling without
# producing build-time side effects.
function(itk_beta_module_manifest _name)
# arguments are intentionally discarded; parsed by external tooling.
endfunction()

# Include every *.beta.cmake so CMake at least syntactically validates
# them at configure time. This does not enable, build, or fetch anything.
# CONFIGURE_DEPENDS asks CMake to re-glob whenever a manifest is added,
# removed, or renamed, so a Beta-module ingest does not require a manual
# `cmake .` reconfigure.
file(GLOB _beta_manifests CONFIGURE_DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/*.beta.cmake")
foreach(_manifest ${_beta_manifests})
include(${_manifest})
endforeach()
unset(_beta_manifests)
unset(_manifest)
4 changes: 2 additions & 2 deletions Modules/Remote/CMakeLists.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ set_property(
"0")
mark_as_advanced(FORCE ITK_MINIMUM_COMPLIANCE_LEVEL)

file(GLOB remotes "*.remote.cmake")
file(GLOB remotes CONFIGURE_DEPENDS "*.remote.cmake")
foreach(remote_module ${remotes})
include(${remote_module})
endforeach()
Expand All @@ -25,7 +25,7 @@ endforeach()
# a separate subdirectory to assist with distinguishing
# different remote module types.
if(Module_ITKDeprecated)
file(GLOB remotes "Deprecated/*.remote.cmake")
file(GLOB remotes CONFIGURE_DEPENDS "Deprecated/*.remote.cmake")
foreach(remote_module ${remotes})
include(${remote_module})
endforeach()
Expand Down
Loading