This PR adds a pluggable registry to extend rendering behavior via end user code. This will allow users to write their own renderers (or themes) in Python and override the default behavior.
Both gos.renderers and gos.themes are instances of PluginRegistry.
Usage
Users can register and enable their own renderers manually. As a reminder, a renderer is any function that accepts a Gosling specification as a Python dict, and returns a Python dict in Jupyter’s MIME Bundle format
def my_custom_renderer(spec: dict) -> dict:
...
import gosling as gos
vis = gos.Track(...).encode(...).view()
# add a custom renderer explicity
gos.renderers.register("my-renderer", my_custom_renderer)
# enable the renderer for the workflow
gos.renderers.enable("my-renderer")
# automatically use renderer
vis
and manually switch back to the default,
# reenable
gos.renderers.enable("default") # switch back to normal
vis # uses the register renderer
or alternatively they can enable plugins in a controlled manner
with gos.themes.enable("dark"):
vis.save("index.html") # dark theme just enabled for this block
gos.themes.active # ""
Automatic registration for renderers & themes in third-party packages
While the above is nice for many situations, we also want to enable third-party libraries the ability to implement plugins and have those automatically enabled for users.
For example, let's say I implement a custom HTML renderer for gos that I want to share with a colleague. Ideally one could just pip install a package and use this with Gos, i.e.,
This is exactly what this PR supports. Package authors need to add an entrypoint to their setup.cfg or setup.py with the custom group name, and they will be discoverred automatically by the PluginRegistry.
This PR adds a pluggable registry to extend rendering behavior via end user code. This will allow users to write their own renderers (or themes) in Python and override the default behavior.
Both
gos.renderers
andgos.themes
are instances ofPluginRegistry
.Usage
Users can register and enable their own renderers manually. As a reminder, a renderer is any function that accepts a Gosling specification as a Python dict, and returns a Python dict in Jupyter’s MIME Bundle format
and manually switch back to the default,
or alternatively they can enable plugins in a controlled manner
Automatic registration for renderers & themes in third-party packages
While the above is nice for many situations, we also want to enable third-party libraries the ability to implement plugins and have those automatically enabled for users.
For example, let's say I implement a custom HTML renderer for gos that I want to share with a colleague. Ideally one could just pip install a package and use this with Gos, i.e.,
This is exactly what this PR supports. Package authors need to add an entrypoint to their
setup.cfg
orsetup.py
with the custom group name, and they will be discoverred automatically by thePluginRegistry
.example