Defining event schema with well-known paths?

[bollwyvl]

I've taken a look at the code and the docs here and upstream in Server, and only see reference to the python-side event registration.

For cases like a labextension, is it possible to register an event by putting a declarative file in a place at packaging time?

I could imagine two approaches:

event-schema-at-rest

{sys.prefix}/
  share/
    jupyter/
      events/
        my-custom-event.yaml

event-schema-in-traitlets

{sys.prefix}/
  etc/
    jupyter/
      jupyter_server_config.d/
        my-custom-event.json

{
  "EventLogger": {
    "extra_schemas": {
      "my-custom-event": {
        "$id": "http://event.jupyter.org/test",
        "version": 1,
        "title": "Simple Test Schema",
        "description": "A simple schema for testing",
        "type": "object",
        "properties": {
          "prop": {
            "title": "Test Property",
            "description": "Test property.",
            "type": "string"
          }
        }
      }
    }
  }
}

My preference, I guess, would be to the former, as nesting schema inside anything is kinda nightmarish, but there is a certain simplicity in keeping everything in traitlets, for good or bad.

[kevin-bates]

I really like the idea of the schema at rest proposal and operators will too - thanks @bollwyvl. I almost like it so much that I wonder if it should be the only way schemas are registered - so there's only one mechanism. The horse may have left the barn on that one, but it might be worth discussing. This way, there's a single location to see which events are "in play" and where others can vet what kind of data is produced, build consumer scripts for handling the output, etc.

[bollwyvl]

Well, this is Jupyter, and dynamic is always useful, if only for a small subset of customized tasks.

single location

Well, this is Jupyter, so it will never be a single location. 🤣 Let's get some entry_points in there, too. Some env vars. Heck, let's make a REST endpoint and add another sqlite to store them. Events for everyone.

which events are "in play" and

Yep, though I'd reckon jupyter events schemas --json is probably a better target than guessing at files-on-disk.

But, of course: I don't think events should be the only thing extensible with schema, so eventually something like...

• jupyter schemas list

  Title               Metaschema ID
  Events v1           https://schema.jupyter.org/meta/events.v1.json
  Commands v1         https://schema.jupyter.org/meta/commands.v1.json
  

• jupyter schema list https://event.jupyter.org/event-metaschema --json

  {
    "schemas": {
      "https://schema.jupyter.org/meta/events.v1.json": {
        "https://my.org/jupyter/schema/custom.v1.json": {
          # ...
        }
      }
    }
  }

[kevin-bates]

Thanks Nick. I'm having trouble deciphering if this (or a portion thereof) is sarcasm or not. If not, it sounds like a "more the merrier" is what you're after. Using entry_points occurred to me as well, but you started this issue off implying that non-"python-side" approaches were needed. I prefer to limit support matrix sizing and would argue that fewer is better (provided all needs are satisfied).

A kernelspec-like CLI makes sense to gather schemas.

[bollwyvl]

See also jupyter/enhancement-proposals#107