4 September 2014 meeting

Agenda

Discussion about how Chimera2 will discover tools.

From Conrad: Currently, Chimera 1 scans through all subdirectories of the "share" folder for ChimeraExtension.py files to locate all the tools. This is somewhat wasteful (most of the time the results are the same) but makes adding new tools simply (always discovered on next restart). For Chimera 2, we add tools using the "Tool Shed" interface mostly, in which case we can maintain a database that is updated only when tools are added instead of rescanning each startup. (Obviously, we will need some sort of interface to add locally developed tools and to force rescanning in case the database is out-of-date or corrupted, but that's pretty straightforward.)

The database should contain a list of the tools and some metadata about the tools. The metadata may be used to invoke a standardized API for things like:

• listing the tool (eg in the Tools menu in the GUI)
• registering supported I/O formats
• registering command line commands
• specifying a custom startup function (for really advanced tools)

If this sounds reasonable, then we should start defining the "Tool Startup" API. The metadata can be stored as either part of the wheel metadata or as a separate file. (The latter is to help simplify installing locally developed tools without having to create a wheel each time.) The syntax of the metadata may be settled later, but we should get a list of the data that need to be supported.

Action items

Future issues

• Documenting our API with Sphinx
• Handling "private" modules -> future exports
• how chimera discovers tools on startup
• debugging from source tree
• build tools
• How do we handle multiple installations
  • Need some mechanism to get "current" tool set
• How to add web services as tools
• Does tool database incorporate wheel metadata?
• Is the local tool database a full copy of tool shed database?
  • How to handle local information (Version, Installed, Enabled, etc.)?

Decisions