JupyterLab Weekly Meeting Minutes 08-04-2020

[tgeorgeux]

JupyterLab Weekly Meeting Minutes

08 Apr 2020 Weekly Meeting

• Eric

  • Extension Manager for 2.1: Polishing PRs - Thx Jason and Saul for reviews and merges
  • Jupyterlab renderers upgrade to jupyterlab 2.1
  • Playing with Webpack Federation for other project, pulling jlab react widgets from remote

• Ed

  • Check in on
    • Refactor Completer API jupyterlab#8080
    • Deprecated Completions UI jupyterlab#8137
    • Icons for Completion Items UI jupyterlab#8140
    • Completer Documentation Panel UI jupyterlab#8141
  • Saul, Darian, Tim are looking at these this week

• Saul

  • Things have been released...
  • A few questions on releasing...
    • How do we get to end goal of hitting a button to release on Github?
      • auto generate changelog, enforcing stricter syntax in PR description
      • figure out what backports should/could be done for each PR
    • How often do we release things?
      • If we can automate, it makes it less of a burden to actually do release
      • and so "when" it happens can be based more on first principles than on who is available (maybe?)
    • Should we be clearer about our intentions, both around getting PRs in and doing releases? So that we understand the conflicting priorities possibly between our employer's desires and the project's needs?
    • As a benchmark, this release took somewhere between 16-30 hours of Saul's time and 16-30 hours of Jason's time
      • changelog took maybe 12 hours total
  • Make an issue for Testing automation on releases
    • Easier, More Regular Releases  jupyterlab#8195

• Jason

  • Exploring webpack module federation and other issues around the extension system rework
  • Will try to set up a meeting with at least Eric and Steve later this week to push forward

• Darian

  • Debugger update

• Tim

  • I would like to set up a meeting with UCI teams and stakeholders for Debugger and JupyterLab-FS/Data Explorer stuff.

• Alex

  • Elyra added a beta code snippet extension yeserday (https://github.com/elyra-ai/elyra)
  • What's the git extension 2.0 support timing looking like and can I aid in speeding it up?
    • [WIP] Update for JupyterLab 2.0 jupyterlab-git#520
      • revert to b00da65
      • rebase on top of master

Aditional Discussion:

• Releases:
  • We released 2.1.0 and 2.0.2 (thanks Saul!)
  • We still have the beta freeze at 19 Jun 2020, so if you plan to work on a major feature, now is a good time to plan out the work.
• New Zoom channel, takes effect next week:
  • https://zoom.us/my/jovyan
  • https://zoom.us/j/546199338
  • Tim to change readme
• Extension system rework
  • Concerns we are addressing:
    • Can we ship an extension that does not require a post-install phase that re-compiles the JupyterLab application? In other words, can an extension be a simple set of static assets that resides in a well-known location? Can I untar some file into a directory and refresh the page and have it magically work?
      • System is not magic for extension authors: Giving extension authors more control over the environment their code is built in, before being run in the browser, would be useful. For example, currently we run all extensions in our webpack config. This is an issue, if extensions have their own config they would rather run. It's also confusing for them, because the post install build step is opaque and not documented. So when it fails (as pointed out above) we get weird issues. Also, it fails on user machines, not extension athors machines, which is even harder to debug.
    • Track versioning between frontend extensions, backend extensions, jupyterlabs server versions, jupyterlab version. We currently have two package manager resolutions working seperately. It would be nice if we could just use one to properly resolve versions between frontend and backend code and extensions.
    • One package per extension, even if that involves both a frontend and backend component
    • A way to minimize the download size for clients on slow networkd
    • debuggability
    • Make it easier to develop multiple extensions independently
    • allow for the creation of seperately deployable built artifacts from each extension