Make it possible to create blocks from Python?

[wolfv]

Potentially we could define some custom blocks from a Python script or from a Notebook if we use some decorators.

Something like:

@block
def myfunction(a: int, b: int) -> int:
    return a + b

[bollwyvl]

Having been down this road a few times before for a couple machine/human languages: while having syntactic sugar for individual languages is really good, the bigger Jupyter-level payoff is formalizing a static version of the block specification, the i10n, and the implementation pattern.

I think the play here is to use #71's upgrade of blockly-9-with-better-typings to nail down, and lightly extend, the blockly JSON schema with ts-to-jsonschema or equivalent, and call these a family of mimetypes:

• application/jp-blockly-block-definition+json
• application/jp-blockly-block-generator+json
• application/jp-blockly-i10n+json
• application/jp-blockly-workspace+json

A couple different tools could then create and consume these from different places.

jupyterlab-blockly-extension:display-blocks

In the example above, the decorator would emit a application/jp-blockly-block-definition+json, that would dynamically extend the blocks available at runtime to all workspaces with a compatible mimetype.

As it would already be in python, it would be possible to do lots of the grunt work, with some baked-in knowledge. The package that provides this decorator (and siblings) probably should not depend on jupyterlab.

jupyterlab-blockly-extension:mime-blocks

But what would it actually look like? Intermediate mime values aren't usually looked at, they are just expected to work. A way to make this more visible and interactive would be allowing for users (and by extension, labextensions, or any other package) to build their own custom blocks as a file that can be moved around, as well as in JupyterLab settings.

Combined with the overrides.json (and overrides.d) approaches, other labextensions could extend the known blocks without a dependency on this extension, or everything having to go in this library, and, crucially, would only need to ship jupyterlab/user-settings.

This would wrap blocks with more jupyter-specific knowledge, anchored on, for example, kernel mimetypes (or patterns).

{
  "application/jp-blockly-block-definition+json": {
    "my-extension:math_change": {
      "message0": "change %1 by %2",
      "args0": [
        {
          "type": "field_variable",
          "name": "VAR",
          "variable": "item",
          "variableTypes": [""]
        },
        { "type": "input_value", "name": "DELTA", "check": "Number" }
      ],
      "previousStatement": null,
      "nextStatement": null,
      "colour": 230
    }
  },
  "application/jp-blockly-block-generator+json": {
    "my-extension:math_change": {
      "text/x-ipython": {
        "text/nunjucks+js": "[`{{ Python.valueToCode(block, 'VAR') }} + {{ Python.valueToCode(block, 'DELTA') }}`, `{{ Python.ORDER_ADDITIVE }}`]"
      }
    }
  }
}

yes there's dynamic codegen... but... this is blockly. them's the brakes...

While this would be no fun to write by hand, there are nice examples of building blockly with blockly, meaning a template could also be implemented as a workspace.

ncbonvert --to blockly-blocks

Once blocks are in outputs, it gets a lot easier to pull things out than a live kernel.

A CLI-level jupyter nbconvert --to blockly-blocks would make it relatively painless to generate and distribute closed-form versions of the above.