pieper
April 2, 2024, 8:40pm
2
Thanks for your patience. Just so you know, there’s ongoing discussion and work on how to improve the extension process so that review of proposed extensions doesn’t become a bottleneck for progress. We want to set expectations correctly about how to make extensions available and what users can expect in terms of completeness and support while also simplifying the process for everyone.
You could refer to and perhaps participate in the discussion below to be sure your thoughts as an extension developer are reflected in the design.
During our last Slicer developer hangout of March 13th 2024, we discussed the issue that review and approval of new extensions often takes very long time. We identified that the main difficulty was that extensions had to meet many requirements to be admitted to the Extensions Catalog. Reducing the requirements could make extensions approval easier but it could result in having lower quality extensions (harder to use, not well documented or tested, etc.).
To address this problem, we propose orga…
Slicer:main ← jcfr:transition-extensions-index-build-system-from-s4ext-to-json
opened 07:05PM - 13 Mar 24 UTC
Implements changes to the Extensions build-system, transitioning from `.s4ext` f… iles to `.json` files for extension catalog entries. Additionally, it updates the ExtensionWizard and module templates to reflect this change and supports contributing `.json` files to the ExtensionsIndex.
As the category is now expected to be defined in the extension catalog entry file, the support for setting the "Category" directly from the ExtensionWizard UI has been removed.
While a .s4ext file is still generated in the built-tree and included in the extension package, this is considered an implementation detail to be addressed in subsequent commits.
The motivations behind these changes include:
* Eliminate redundant and unused information from the "description" file.
* Simplify programmatic parsing of the "description" files
* Decouple the metadata organized in the extension `CMakeLists.txt` from
the ones organized in this repository and used to drive the build of extensions.
* Enable Slicer maintainers to define and update the extension "category"
and "enabled" metadata independently of the upstream extension sources.
----
It removes the parsing and handling of metadata already defined in the extension `CMakeLists.txt` by the extension index build-system.
The metadata values now extracted from the `<extensionname>.s4ext` file locally generated in the extension build tree are the following:
- "contributors"
- "depends" (runtime dependencies)
- "description"
- "iconurl"
- "homepage"
- "screenshots"
The only metadata values propagated from the `Slicer/ExtensionsIndex` files now formatted as JSON files (`<extensionname.json`) are the following:
- "scm", "scmurl" and "scmrevision"
- "category"
- "build_dependencies"
- "build_subdirectory"
- "enabled"
The extension name is still derived from the catalog entry filename.
Related:
* https://github.com/Slicer/ExtensionsIndex/pull/2011
* https://discourse.slicer.org/t/introduction-of-tiers-for-slicer-extensions/34870