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

Local Tool Database Metadata

• name
• synopsis
• icon
• file type(s) support (suffix and mime type)
• tool category
• command prefix word
• PMID(s)
• authors
• website
• institution
• version
• installed boolean
• enabled boolean
• startup boolean

Toolshed Functionality

1. populate commands
2. populate I/O formats
3. populate menus

Proposed App Startup

1. initial program/script that
   • updates environment to not affect embedded python
   • starts up embedded python with application initialization module
2. application initialization module:
   • parses command line arguments
   • monkey patch python to restore original environment if calling outside program
   • make sure HOME environment variable is set
   • --send: pass arguments to already chimera and exit
   • if have GUI, display splash screen
   • diagnostic output and exit, e.g., --version
   • basic initialization
   • additional startup tool initialization
   • open models and run scripts given on command line
   • start event loop