langage bindings - conf file based block registry

[guruofquality]

Problem

Looking at pothos-python and future work on pothos-java, it looks like there is a general problem to be solved of making blocks written in high level languages available to the block registry without actually compiling any pothos plugins.

Solution

it should be possible to make a block in python, install it, and inform the block registry somehow that it exists. Currently the python project comes with cmake utils that builds a minuscule plugin module wrapper and embeds the block description. But the wrapper is just a function that gets built with a namespace and block path, and the block description is just a JSON string. This is paradigm that can be generalized -- and a generic plugin loader in the core library can handle loading both the factory function and the block description

Conf files

The issue purposes a .conf style file that describes a block via:

• plugin registry path
• import/namespace path
• language python/java
• path to block description

Example

baz_myBlock.conf

[myBlock]
path = /baz/myBlock
namespace = baz.MyBlock
language = python
description = ./docs/baz_myBlock.json

[myBlock2]
could be multiple blocks here...

Loader operating

• The plugin loader (on library plugin initialization) will scan global and home conf.d/ style directories for these descriptive conf files. (ex /prefix/share/Pothos/blocks, $HOME/.conf/Pothos/blocks)
• For every block discovered, the description will be loaded into the plugin tree under /blocks/docs/path. And a function will be registered under /blocks/path that has the language and namespace bound as arguments.
• When invoked, the bound function will pass all input arguments and bound arguments to the language-specific handler. Additional arguments such as module/class search paths could be recorded in the conf file and bound and passed here as well.
• An example handler might open the proxy environment for that language and find the block's factory given the import namespace. This factory will be called with the import arguments and the result returned as a new block.

Wrapping it up

At the very least, the python cmake build helpers will be updated to create and install the conf file. One might also consider non-cmake build helpers, like an all python script or all java script to build and install said blocks -- even just to the home directory.