Hello,
I am trying to upload this extension, but for some reason I am getting this error about a documentation url… I followed all the instructions here and the --describe option works fine.
I’ve never needed command-line interface of ExtensionWizard. You can do all Slicer-specific operations using graphical user interface of ExtensionWizard module. I find pushing files, sending pull requests simpler to do using generic tools (simple git commands) rather than learning ExtensionWizard commands.
Does anybody use ExtensionWizard command-line? For what operations? Maybe we can delete rarely used commands to reduce associated documentation, testing, support, and maintenance work.
2 Likes
So to upload my extension to the extension manager, do I just have to make an s4ext file and submit a pull request to https://github.com/Slicer/ExtensionsIndex?
Yes! And the s4ext file should be created automatically in the build directory for your extension.
Me neither, but as I was looking for the page with the instructions to share with @moselhy, I found that slicerExtensionWizard --contribute is mentioned as one of the recommended approaches for contributing extensions, and it definitely looks more attractive than the other option, see Documentation/Nightly/Developers/Tutorials/BuildTestPackageDistributeExtensions - Slicer Wiki.
I can see how the other option mentioned can be confusing to a beginner:
Fork ExtensionIndex repository (GitHub - Slicer/ExtensionsIndex: Slicer extensions index), add your extension, and send a pull request
1 Like
I’ve added more specific instructions about how to upload a .s4ext file to the ExtensionIndex to a forked repository and send a pull request (although nowadays most developers use GitHub, so already familiar with the workflow). It is nice that all steps (fork repository, upload file, send pull request) are available directly on the web interface, by a few clicks.
The good news, is that this is already the case. The description is created in the build directory of every extension
Our of curiosity and to put things in context, which “other options” are you referring to ? It looks like the wiki page always suggested to use slicerExtensionWizard --contribute
Agreed. Now that few years went by, it may a good time to streamline the process.
@jcfr there were (and still are, after @lassoan edits) two options listed on the wiki: make a pull request manually, or use slicerExtensionWizard to automatically make a pull request with --contribute.
I see.
There are indeed two pages linked of the extension How-tos:
- Contribute Extension Description File using Extension Wizard
- Manually contributing an extension description file
That said, the main point of entry Create Slicer Extension linked of the build instructions found on the main page (and also in the new member check list) only mention the extension wizard approach. If you think that would help reduce confusion (if any), we could remove that second page ?
I must be missing something - it actually mentions both approaches.
"If you consider your extension is ready for distribution, contribute it to the ExtensionsIndex:
- Fork ExtensionIndex repository on GitHub by clicking Fork button on GitHub - Slicer/ExtensionsIndex: Slicer extensions index 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:"
I missed that. The initial version was only mentioning the extension wizard. See here
Then, in Nov 2016, @lassoan improved the page explaining that both approaches were possible. See here and more recently updated adding details about s4ext. See here
@fedorov Would you suggest to remove the mention of pull request ? Or should we change the text to something like:
I feel that the world has changed a lot in the last few years. Git and GitHub has become mainstream, so forking, branchinc, modifying files, and sending pull request are the norm. ExtensionWizard’s commands shorten the command line but they are non-standard and hide what happens internally, making things look more complex than they really are.
We can keep the scripts as they are and documentation will be generated for it automatically, but I don’t think we should advertise them on the wiki at all.
3 Likes
I agree with Andras. Slilcer ExtensionWizard is a “one off” thing that developers need to take effort to remember how to use, and it doesn’t always work. Working with git and GitHub is an essential skill that every open source developer should be motivated to learn. I certainly hope that developers contributing extension to Slicer are familiar with the basics of GitHub, such as how to make a PR!
1 Like
Thank you for the clarification. See this pull request.
Yes! And the s4ext file should be created automatically in the build directory for your extension.
I had to generate the description file using the bin/slicerExtensionWizard --describe command and save the output into the .s4ext file, because I couldn’t find the s4ext file in my build directory. Is this a bug or am I doing something wrong?
1 Like
I don’t know. I personally never used the auto-generated s4ext.
@moselhy You can find it in the build tree. For example:
$ git clone https://github.com/moselhy/SequenceRegistration
$ mkdir SequenceRegistration-build
$ cd SequenceRegistration-build/
$ cmake -DCMAKE_BUILD_TYPE:STRING=Release -DSlicer_DIR:PATH=/home/jcfr/Projects/Slicer-2-build/Slicer-build/ ../SequenceRegistration
$ make -j6
[...]
-- Configuring Scripted module: Elastix4D
-- Extension description has been written to: /tmp/SequenceRegistration-build/SequenceRegistration.s4ext <------------
[...]
-- Build files have been written to: /tmp/SequenceRegistration-build
$ pwd
/tmp/SequenceRegistration-build
$ ls *.s4ext
SequenceRegistration.s4ext
You should also see the following message reported when configuring:
Extension description has been written to: /tmp/SequenceRegistration-build/SequenceRegistration.s4ext
Content of the generated file:
$ cat SequenceRegistration.s4ext
[...]
# This is source code manager (i.e. svn)
scm git
scmurl https://github.com/moselhy/SequenceRegistration
scmrevision 39fe467
# list dependencies
# - These should be names of other modules that have .s4ext files
# - The dependencies will be built first
depends Sequence SlicerElastix
# Inner build directory (default is ".")
build_subdirectory .
# homepage
homepage https://github.com/moselhy/SequenceRegistration
# Firstname1 Lastname1 ([SubOrg1, ]Org1), Firstname2 Lastname2 ([SubOrg2, ]Org2)
# For example: Jane Roe (Superware), John Doe (Lab1, Nowhere), Joe Bloggs (Noware)
contributors Mohamed Moselhy (Western University), Andras Lasso (PerkLab, Queen's University)
# Match category in the xml description of the module (where it shows up in Modules menu)
category Registration
# url to icon (png, size 128x128 pixels)
iconurl https://raw.githubusercontent.com/moselhy/SequenceRegistration/master/Elastix4D/Resources/Icons/Elastix4D.png
# Give people an idea what to expect from this code
# - Is it just a test or something you stand behind?
status
# One line stating what the module does
description This will register a multi-volume sequence using Elastix.
# Space separated list of urls
screenshoturls https://raw.githubusercontent.com/moselhy/SequenceRegistration/master/screenshot.png
# 0 or 1: Define if the extension should be enabled after its installation.
enabled 1
1 Like
Thank you, it makes sense now
1 Like