just an idea: previously we mentioned establishing duct-suite but now that we have it as con-duct on pypi and con_duct python module, it should just be con-duct CLI...

This way, eventually, someone could even come up with con frontend to all con-* tools if we follow's git's approach of git- prefix and just taking any git-blah into git blah ;-)

WDYT @asmacdo !

• con-duct is made available in default lean installation, although sub-commands (to function) might require additional components
  • should provide listing of those commands (click library does that for you)
  • @yarikoptic thinks that by default those commands should be available and if executed but requiring an external (e.g. matplotlib) they should error out and announce that.
    • Very weak may be: con-duct --help listing of those commands could mention what those dependencies are and/or either they are installed.
• (may be) Make duct == con-duct run so it is nicely visible in con-duct --help which would list the commands
• (later) Make con-duct "dynamically extensible" similarly to how either git or datalad do it
  • git blah is picking up any git-blah in PATH (after considering built-ins under /usr/lib/git-core).
    • called by some "command dispatcher pattern" (and makes analogies to GoF's Mediator pattern)
    • since CLI, defines protocols for git-remote-* etc helpers
    • similarly git-annex defines protocol for git-annex-remote- helpers, but AFAIK does not extend git annex COMMAND namespace
  • datalad uses Python entry points under the common prefix (datalad.) and conventions for interfaces to define in its "datalad-extensions"