Difference between revisions of "Documentation/Nightly/Developers/Tutorials/BuildTestPackageDistributeExtensions"

From Slicer Wiki
Jump to: navigation, search
Line 33: Line 33:
 
=== Contribution Checklist ===
 
=== Contribution Checklist ===
  
* Wait for your pull request to be merged. Respond to comments posted on the pull request. Reviewers will check the followings:
+
* Wait for your pull request to be merged. Respond to comments posted on the pull request. Reviewers will associate the following checklist with your pull request:
** Extension has a reasonable name (not too general, not too narrow, suggests what the extension is for)
+
{{pre2|
** Repository name is Slicer<ExtensionName>
+
Thank you very much for your contribution. Here is list of minimum requirements that are necessary to give users a chance to find out what your extension is about and how to use it:
** Extension description summarizes in 1-2 sentences what the extension is usable (should be understandable for non-experts)
+
 
** Extension URL and revision (scmurl, scmrevision) is correct, consider using a branch name (master, release, …) instead of a specific git has to avoid re-submitting pull request whenever the extension is updated
+
* [ ] Extension has a reasonable name (not too general, not too narrow, suggests what the extension is for)
** Extension icon URL is correct
+
* [ ] Repository name is `Slicer<ExtensionName>`. However, this is not a mandatory requirement. If there is a compelling reason not to use Slicer prefix, please make a note while making the pull request.
** Screenshot URLs (screenshoturls) are correct, contains at least one
+
* [ ] Extension description summarizes in 1-2 sentences what the extension is usable (should be understandable for non-experts)
** Homepage URL points to valid webpage containing the followings:
+
* [ ] Extension URL and revision (`scmurl`, `scmrevision`) is correct, consider using a branch name (master, release, …) instead of a specific git has to avoid re-submitting pull request whenever the extension is updated
*** Extension name
+
* [ ] Extension icon URL is correct
*** Short description: 1-2 sentences, which summarizes what the extension is usable for
+
* [ ] Screenshot URLs (`screenshoturls`) are correct, contains at least one
*** At least one nice, informative image, that illustrates what the extension can do. It may be a screenshot.
+
* [ ] Homepage URL points to valid webpage containing the followings:
*** Description of contained modules: at least one sentence for each module
+
  * [ ] Extension name
*** Tutorial: step-by-step description of at least the most typical use case, include a few screenshots, provide download links to sample input data set
+
  * [ ] Short description: 1-2 sentences, which summarizes what the extension is usable for
 +
  * [ ] At least one nice, informative image, that illustrates what the extension can do. It may be a screenshot.
 +
  * [ ] Description of contained modules: at least one sentence for each module
 +
  * [ ] Tutorial: step-by-step description of at least the most typical use case, include a few screenshots, provide download links to sample input data set
 +
 
 +
_This checklist was copied from the [Step-by-step: How to create, publish, distribute and maintain an extension ?](https://www.slicer.org/wiki/Documentation/Nightly/Developers/Tutorials/BuildTestPackageDistributeExtensions#Contribution_Checklist) guide available Slicer wiki._
 +
}}
 
* Next day after your pull request is merged, check on the [https://www.slicer.org/wiki/Documentation/Nightly/Developers dashboard] if your extension is built successfully on all platforms.
 
* Next day after your pull request is merged, check on the [https://www.slicer.org/wiki/Documentation/Nightly/Developers dashboard] if your extension is built successfully on all platforms.
  

Revision as of 18:05, 5 December 2018

Home < Documentation < Nightly < Developers < Tutorials < BuildTestPackageDistributeExtensions


For the latest Slicer documentation, visit the read-the-docs.


To learn what is an extension, see here

Step-by-step: How to create, publish, distribute and maintain an extension ?

  • Scan through the user and developer extension FAQs
  • Inform a community about your plans on the Slicer forum to get information about potential parallel efforts (other developers may already work on a similar idea and you could join or build on each other's work), past efforts (related tools might have been available in earlier Slicer versions or in other software that you may reuse), and get early feedback from prospective users. You may also seek advice on the name of your extension and how to organize features into modules. All these can save you a lot of time in the long term.
  • Optional (required if developing loadable or CLI module types): Build Slicer application in Release. Not needed if you only develop Python modules.
  • Use the Extension Wizard module in Slicer to create an extension that will contain your module(s). Learn more about ExtensionWizard capabilities here. To learn about extension description file format see here
  • Upload source code of your extension to a publicly available repository. It is recommended to start the repository name with "Slicer" (to make Slicer extensions easier to identify) followed by your extension name (for example, "Sequences" extension is stored in "SlicerSequences" repository). However, this is not a mandatory requirement. If you have a compelling reason not to use Slicer prefix, please make a note while making the pull request.
    • GitHub is recommended (due to large user community, free public project hosting): join Github and setup Git
    • Extension Wizard command-line interface can upload source code of your extension to GitHub:
$ bin/slicerExtensionWizard --publish ~/Slicer-MyExtension/
  • Implement your extension. Hack, hack, hack :).
  • Create documentation page for your extension
  • Optional (only needed, if you want to upload test data to MIDAS or troubleshoot extension upload problems): Create an account on the extension server and obtain an API Key. You will then use your midas login and api key to substitute <YOUR-MIDAS-LOGIN> and <YOUR-MIDAS-APIKEY> in the examples. Go to NA-MIC community and click on Join community

  • Optional (required for loadable and CLI modules): Build your extension
  • Test your extension:
    • If you have built your extension then build the PACKAGE target to create a package file that you can install from the Extension Manager by clicking the small tool icon in the top-right corner.
    • If you have not built your extension then set up your extension manually: Build your extension
  • If you consider your extension is ready for distribution, contribute it to the ExtensionsIndex:
    • Fork ExtensionIndex repository on GitHub by clicking Fork button on https://github.com/Slicer/ExtensionsIndex page
    • Add your .s4ext file to your forked repository: it can be done using a git client or simply by clicking Upload files button
    • Create a pull request: by clicking Create pull request button
    • Note: the Extension Wizard can automate this by the following command:
$ bin/slicerExtensionWizard --contribute ~/Slicer-MyExtension/

Contribution Checklist

  • Wait for your pull request to be merged. Respond to comments posted on the pull request. Reviewers will associate the following checklist with your pull request:
Thank you very much for your contribution. Here is list of minimum requirements that are necessary to give users a chance to find out what your extension is about and how to use it:

* [ ] Extension has a reasonable name (not too general, not too narrow, suggests what the extension is for)
* [ ] Repository name is `Slicer<ExtensionName>`. However, this is not a mandatory requirement. If there is a compelling reason not to use Slicer prefix, please make a note while making the pull request.
* [ ] Extension description summarizes in 1-2 sentences what the extension is usable (should be understandable for non-experts)
* [ ] Extension URL and revision (`scmurl`, `scmrevision`) is correct, consider using a branch name (master, release, …) instead of a specific git has to avoid re-submitting pull request whenever the extension is updated
* [ ] Extension icon URL is correct
* [ ] Screenshot URLs (`screenshoturls`) are correct, contains at least one
* [ ] Homepage URL points to valid webpage containing the followings:
  * [ ] Extension name
  * [ ] Short description: 1-2 sentences, which summarizes what the extension is usable for
  * [ ] At least one nice, informative image, that illustrates what the extension can do. It may be a screenshot.
  * [ ] Description of contained modules: at least one sentence for each module
  * [ ] Tutorial: step-by-step description of at least the most typical use case, include a few screenshots, provide download links to sample input data set

_This checklist was copied from the [Step-by-step: How to create, publish, distribute and maintain an extension ?](https://www.slicer.org/wiki/Documentation/Nightly/Developers/Tutorials/BuildTestPackageDistributeExtensions#Contribution_Checklist) guide available Slicer wiki._
  • Next day after your pull request is merged, check on the dashboard if your extension is built successfully on all platforms.

Continuous Integration

If you shared your extension by using the ExtensionWizard, make sure you know about the Slicer testing dashboard:

CDash-logo.png http://slicer.cdash.org/index.php?project=Slicer4&display=project

The dashboard will attempt to check out the source code of your extension, build, test and package it on Linux, MacOSX and Windows platforms.


To find your extension, use the following link replacing Slicer-MyExtension with the name of your extension:

http://slicer.cdash.org/index.php?project=Slicer4&filtercount=1&showfilters=1&field1=buildname&compare1=63&value1=Slicer-MyExtension

For example, here is the link to check the status of the SlicerDMRI extension:

http://slicer.cdash.org/index.php?project=Slicer4&filtercount=1&showfilters=1&field1=buildname&compare1=63&value1=SlicerDMRI

If you see red in any of the columns for your extension, click on the hyperlinked number of errors to see the details.

Always check the dashboard after you first introduce your extension, or after you make any changes to the code!