BUG: Corrected links to icon and screenshot.

[ClementMirabel]

I had never noticed the icon was not displaying well in the Slicer Extension Manager because the URL was wrong. Never too late to correct it.

[fedorov]

@ClementMirabel you probably also want to update these lines accordingly: https://github.com/ClementMirabel/DatabaseInteractorExtension/blob/master/CMakeLists.txt#L11-L12. I know because I went over this exercise earlier for one of the extensions I support.

@jcfr what was the thought of duplicating those links between s4ext and the extension cmake? What makes it even more confusing, that (at least for some of these items) the content of s4ext is ignored, and the factory machine is using the values from CMakeLists.txt.

Related to the earlier discussion, would be nice to improve the schema of s4ext files - we track things that are not that important in multiple places, but there is no well-defined and prominent location to track publications that should be cited for a given extension, or grants that funded its development.

[ClementMirabel]

Thank you for pointing that, I was not really sure which one between the CMakeLists.txt and the s4ext was used for such a display.

[fedorov]

I am not sure either! ;-D

[lassoan]

The .s4ext file is generated by CMake. You should not store the .s4ext file in your source code repository, just delete it.

[jcfr]

To clarify, currently the authoritative source for metadata is the CMakeLists.txt file. The description file is generated based on the CMakeLists.

See https://www.slicer.org/wiki/Documentation/Nightly/Developers/Extensions/DescriptionFile

For example, the extension wizard used the CMakeLists to generate it.

Information is duplicated for convenience. It make it easy to find out info about an extension without having to checkout is source tree.

Also .s4ext were adapted from the previous format .s3ext, we didn't reinvent the "wheel" on that front.

To conclude, for any extension you build locally, you will have a generated description in its build directory.

[lassoan]

Information duplication does not serve anyone's interest, we should simply remove all s4ext files that accidentally got committed into repositories. We don't have s4ext file in any of our extensions and they work well.

If you want to get a good overview of all available extensions then the best place is the extensions index.

If you want to find out about a specific extension, reading the CMakeLists.txt file is as easy as reading an s4ext file.

[fedorov]

Information duplication does not serve anyone's interest
...
If you want to find out about a specific extension, reading the CMakeLists.txt file is as easy as reading an s4ext file.

👍

we should simply remove all s4ext files that accidentally got committed into repositories

@lassoan the topic in question is duplication of the information between CMakeLists.txt files in the extension repositories, and s4ext file in the ExtensionsIndex.

[lassoan]

OK, I see. Duplication between CMakeLists.txt and s4ext is not ideal but it's a small inconvenience compared to how much work it would be to change the extension build infrastructure.

[fedorov]

Andras, I would like to understand how much effort it is really to change it. If those attributes are not used from s4ext, then they only add confusion, in my opinion.

But more importantly, the fact that we don't have a dedicated location to specify citation and funding grant as extension metadata does bother me.

[jcfr]

we should simply remove all s4ext files that accidentally got committed into repositories.

Exactly.

duplication of the information between CMakeLists.txt files in the extension repositories, and s4ext file in the ExtensionsIndex.

Agreed it could be improved.

In the mean time, it should be quite easy to use the extension wizard to create the pull request with all required info.

[jcfr]

But more importantly, the fact that we don't have a dedicated location to specify citation and funding grant as extension metadata does bother me.

Agreed.

I suggest we move away from this text file ... adapted from the previous file format.

The idea would be to standardize on a json (or yaml or xml ... ) file format with a well defined schema.

The info would be added to a repo named github.com/slicer/slicer-extension-description-spec

With that format defined, we will be able to update the infrastructure.

[fedorov]

it should be quite easy to use the extension wizard to create the pull request with all required info

So when I need to modify a URL to the icon, or screenshot, you really expect the developer to have a working build tree of Slicer and use ExtensionWizard to re-generate s4ext file? There is absolutely no way I am doing that.

This inspired me to make my first ever discourse poll: https://discourse.slicer.org/t/poll-how-do-you-re-generate-s4ext-file-for-slicer-extensionsindex/381 !

[lassoan]

Using json or xml for extension description would be nice. We should choose a format that CMake can parse.

I don't know if there is a good solution for avoiding redundancy of information in:

• extension description file in the extension's zip package (used by the extension manager to render the webpages), and
• extension description file in the ExtensionsIndex repository (that is used by factory machines for building the extensions)

Currently the same s4ext file can be used at both places. If we want to avoid redundancy then we should have two different kinds of "extension description" files (but that would make things more complex). Or we could have a completely different ExtensionsIndex format, for example have just a single json file that contains extension name and repository url and branch/tag name.

[jcfr]

So when I need to modify a URL to the icon, or screenshot, you really expect the developer to have a working build tree of Slicer and use ExtensionWizard to re-generate s4ext file? There is absolutely no way I am doing that.

Agreed.

I do not think are binary here ... there are definitively complementary approaches.

Also worth noting that the extension wizard is available in the installer not only the build tree. May be we should make things more explicit and improve documentation.

[fedorov]

The idea would be to standardize on a json (or yaml or xml ... ) file format with a well defined schema.

There were some related efforts that I've seen somewhere. I need to remember where I saw that, and add here. I will make a labs page to brainstorm.

[fedorov]

I completely forgot about this, but for the reference, here's one schema that we could consider for describing extension metadata: https://github.com/codemeta/codemeta

[fedorov]

And the labs page: https://www.slicer.org/wiki/Documentation/Labs/ExtensionsMetadata