Switch extension index entry format from "s4ext" to "json" | ⚠️ Changes removed from main

[jcfr]

⚠️ Changes originally introduced through this pull-request have been removed from main by force pushing. Corresponding changes are superseded by #7709 ⚠️

Rational:

• Commit message was incorrect
• Changes were integrated using Squash & Merge instead of Rebase & Merge

---

In response to discussions during the Slicer developer hangout on March 12th, we have decided to revamp the organization of extension metadata in the extensions index, transitioning from the s4ext format to json.

---

Implements changes to the Extensions build-system, transitioning from .s4ext files 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:

• CI: Transition from s4ext to json ExtensionsIndex#2011
• https://discourse.slicer.org/t/introduction-of-tiers-for-slicer-extensions/34870

---

Extension description may now use a limited subset¹ of HTML tags and attributes.

Related pull requests:

• ENH: Update ExtensionDetails view to render extension description as html KitwareMedical/slicer-extensions-webapp#159
• Server: Ensure extension description field is html safe girder/slicer_package_manager#123

Footnotes

1. https://github.com/matthiask/html-sanitizer#settings ↩

[lassoan]

Thanks a lot @jcfr the changes look good to me. I've just added a few small comments.

[lassoan]

Thank you, I've added some comments. I'm OK with most of them left unchanged, the only thing that I feel strongly about is that we should include the schema name in the file. I would rather not add lots of json files that are not clear what contain, especially because neither the filename, nor the file extension or file content is specific enough to confidently tell that it is an extensions catalog entry.

[lassoan]

Thank you, it looks good, just marked a few trivial things. If there is any trouble with removing "NA" then it is fine to leave it there.

[jcfr]

If I understand correctly, we should remove the category from here then.

Ditto.

This should be addressed in the commit ENH: Ensure extension category from catalog entry file is used, I still need to test the approach.

Also need to display warnings (when using Slicer >= 5.8) to suggest removal of EXTENSION_CATEGORY and EXTENSION_ENABLED in extension CMakeLists.txt if the corresponding variables are set.

[lassoan]

@jcfr let me know if this is ready for final review

[jcfr]

This is ready for review.

That said, I still need to update the ExtensionIndex based in the new schema and create PR on existing Extension.

[jcfr]

Let me know if this is ready for final review

@lassoan This is now ready for final review.

[pieper]

Impressive work Jc 👍

I don't see anything obviously wrong so if you are comfortable I think we should go ahead. We'll know for sure once we try it for real.

[jcfr]

Thanks for the cursory check.

if you are comfortable I think we should go ahead

On the metroplex factory, I was able to locally build the index and publish an extension so we should be in good shape.

[jcfr]

While ensuring Slicer/ExtensionsIndex#2011 was also passing, I realized I missed one update¹ to the schema, this is now fixed.

@pieper I would appreciate a re-approval

Footnotes

1. https://github.com/Slicer/Slicer/compare/e6151f39214aa197d77b7a6b083d9c4c181ceb8e..783f4015450605930ae9d7f68cf3f1ea7d6418de ↩

[pieper]

👍