"Command type" plugins

[havocp]

The goal here would be to factor out the specific knowledge of Bokeh and notebooks in the code already, replacing them with plugins that can be extended by third parties as well. We could make this the first "plugin type" in a general plugin system (the idea would be that a plugin can implement 1-N interfaces/features, such as "new command type").

[havocp]

A tricky requirement we've come up with here is that we really want the plugin code to run in one of the project's environments, not in anaconda-project's environment. So that may involve for example making plugins be a child process.

[havocp]

Implementation complexity: currently we use notebook/boken-specific knowledge before we "prepare" (create environments). This means if plugins are in those environments we create, something will have to change.

[fpliger]

@havocp do you think we must nail both (plugin in the anaconda-project environment and plugin in the created env) at a first pass (due to anaconda-project implementation defails)? If not we may start doing it at the anaconda-project env first and add the created env in a second pass...

[havocp]

I don't think we'd want two ways to write plugins, we should do it the way we want to keep. Currently lean toward putting plugins in the anaconda-project process/environment because putting them in the child environment doesn't seem all that feasible when I try to work out the details.

[fpliger]

👍 if you already have an idea of how you see the plugin system and where/how to add hooks in the anaconda-project code, I'd be happy to help implementing it (if you need, of course 😄 )

[havocp]

I'll work on writing up some specs/discussion-docs.