deathbeds / jupyterlab-starters

Starter notebooks and directories in JupyterLab

Home Page:https://jupyterstarters.readthedocs.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Move `@deathbeds/jupyterlab-rjsf` to the jupyterlab-contrib org

hbcarlos opened this issue · comments

From the discussion in #97 and jupytercad/JupyterCAD#101. I propose to move the jupyterlab-rjsf package into its repository under the jupyterlab-contrib organization to make it more official and share maintenance load.

cc @bollwyvl @martinRenou @trungleduc

As rjsf is already deeply embedded in JupyterLab core for settings and metadata, I'm 👎 to making it a separate repository, as it would:

  • have no implicit UI that could be tested
    • i guess it could be a mime renderer for .schema.json
    • or it could consume wxyz-json-schema-form
  • introduce the opportunity for duplication of rjsf on the page, which has some dirty global state
  • introduce the opportunity for style conflicts with the overly-broad implementation in core
  • would be another thing that has to get updated and tested with different versions of lab

Being in core means the existing Lab UI would already benefit from the features this implementation offers:

  • markdown labels
  • a sensible approach to custom field-level elements
  • some already-useful components, such as the CodeMirror editor for string/object types

The work it would need to do this better:

  • markdown rendering and CodeMirror need to be rock-solid
  • presumably converting the robot tests to galata
  • better DX for extending/subsetting the registry of field/widget

And, of course, this code is BSD-3-Clause, so feel free to do whatever you want!

I'm not sure I understand some of those points.

have no implicit UI that could be tested
i guess it could be a mime renderer for .schema.json
or it could consume wxyz-json-schema-form

I suppose this could be done later, I'm not sure I understand why that would be related to moving @deathbeds/jupyterlab-rjsf to another place?

introduce the opportunity for duplication of rjsf on the page

Could rjsf be specified as sharedPackages in the package.json? Also, this point does not seem related to moving the repository, as it would already be the case now that we use it in jupytercad (in the case of using both jupytercad and jupyterlab-starters).

would be another thing that has to get updated and tested with different versions of lab

It's actually one of the thing we'd like to do :) To update it for JupyterLab 4 support.

I would see this move as being one step towards moving it into JupyterLab core if that happens one day.

sharedPackages

That's the point: it's not a labextension, at present, just a set of classes, so there's no way to treat rjsf as a sharedPackages in a way that works with the version shipped with core, and would still have to be done per-downstream. Being in core, that problem goes away, and ensures it doesn't conflict with the relatively leaky styling done there.

one step towards

Spending more effort on a dedicated repo seems like a step back vs just improving what's in core. It's half way there after jupyterlab/jupyterlab#13056, thanks to @brichet.

Again, open source, do what you want: I stand by the assessment that the total effort of landing this directly in Lab 4, for whoever does it, and harmonizing with the existing core features, would be lower, and result in a better extension developer and user experience.

It's half way there after jupyterlab/jupyterlab#13056, thanks to @brichet.

Thanks for pointing to this PR, I'll have a look :)

I stand by the assessment that the total effort of landing this directly in Lab 4, for whoever does it, and harmonizing with the existing core features, would be lower

I trust you that's the best approach to take 👍🏽