Documentation/Labs/ExtensionsMetadata - Revision history

Lasso at 17:34, 18 January 2018

2018-01-18T17:34:18Z

JChris.FillionR: /* Background */

2017-08-02T19:48:53Z

Background

Fedorov: Created page with "=Background= Currently, extension metadata is captured (and duplicated) primarily in two locations: 1. Top-level CMakeLists.txt in the extension repository 2. s4ext file in..."

2017-08-02T19:30:51Z

Created page with "=Background= Currently, extension metadata is captured (and duplicated) primarily in two locations: 1. Top-level CMakeLists.txt in the extension repository 2. s4ext file in..."

New page

=Background=

Currently, extension metadata is captured (and duplicated) primarily in two locations:

1. Top-level CMakeLists.txt in the extension repository
2. s4ext file in https://github.com/Slicer/ExtensionsIndex

Notably, the content of s4ext file is used primarily for getting the extension repository and revision. The rest of the metadata is extracted from the CMakeLists.txt file (see [https://github.com/Slicer/ExtensionsIndex/pull/1425 this discussion].

Specifically, the following items are currently captured (all items are unstructured free text, with no validation done or possible):
* source code manager info (scm type, url, revision, username/password - if applicable)
* dependencies
* homepage
* contributors (unstructured text)
* category
* iconurl
* status
* description
* screenshoturls
* enabled

Importantly, the current approach has several deficiencies:
* the unstructured nature of the description, and replication of items between two places, leads to inconsistencies and confusion (based on a [https://discourse.slicer.org/t/poll-how-do-you-re-generate-s4ext-file-for-slicer-extensionsindex/381 small poll], many developers edit s4ext manually)
* the following items that are rather important are not currently included anywhere:
** funding information
** relevant citation that authors would want users to acknowledge
** license

=Ideas=

* We could consider using some version of codemeta https://github.com/codemeta/codemeta to describe Slicer extensions
* to reduce the redundancy, we could make all options in s4ext optional, except the scm information - see discussion in https://github.com/Slicer/ExtensionsIndex/pull/1442

← Older revision		Revision as of 17:34, 18 January 2018
Line 31:		Line 31:
	* We could consider using some version of codemeta https://github.com/codemeta/codemeta to describe Slicer extensions		* We could consider using some version of codemeta https://github.com/codemeta/codemeta to describe Slicer extensions
	* to reduce the redundancy, we could make all options in s4ext optional, except the scm information - see discussion in https://github.com/Slicer/ExtensionsIndex/pull/1442		* to reduce the redundancy, we could make all options in s4ext optional, except the scm information - see discussion in https://github.com/Slicer/ExtensionsIndex/pull/1442
		+	* Add s4ext file generation feature to Extension Wizard to make it easy for Python-only extensions to create metadata file without building Slicer (see this discussion: https://github.com/Slicer/ExtensionsIndex/pull/1505#issuecomment-358719578)

@@ Line 3: / Line 3: @@
 Currently, extension metadata is captured (and duplicated) primarily in two locations:
-. Top-level CMakeLists.txt in the extension repository
+# Top-level CMakeLists.txt in the extension repository
-. s4ext file in https://github.com/Slicer/ExtensionsIndex
+# s4ext file in https://github.com/Slicer/ExtensionsIndex
 Notably, the content of s4ext file is used primarily for getting the extension repository and revision. The rest of the metadata is extracted from the CMakeLists.txt file (see [https://github.com/Slicer/ExtensionsIndex/pull/1425 this discussion].