search

jupyterlab / frontends-team-compass

A repository for team interaction, syncing, and handling meeting notes across the JupyterLab ecosystem.
https://jupyterlab-team-compass.readthedocs.io/en/latest/
BSD 3-Clause "New" or "Revised" License
57 stars 30 forks source link

Move jupyter-ui-toolkit in the JupyterLab organization #227

Open fcollonval opened 7 months ago

fcollonval commented 7 months ago

As the Jupyter toolkit is now used in JupyterLab, I call for a vote to migrate the repository to the JupyterLab organization following the discussion at the weekly call.

To provide more background, the toolkit is today in the JupyterLab community organization that is not officially endorsed by Jupyter. So moving it in this organization will ensure official support for maintenance and publication rights. In addition it will allow some members to contribute as they may not be allowed to do so on the community organization due to company policy.

@jupyterlab/jupyterlab-council the vote is opened up to December 14th, 2023 (anywhere on earth):

jtpio commented 7 months ago

following the discussion at the weekly call.

For context, would you mind linking to the meeting notes where this was discussed?

Maybe also to the issue or PR that added jupyter-ui-toolkit as a dependency to JupyterLab? Thanks!

brichet commented 7 months ago

This has been discussed during November 29, 2023 meeting, but there is no mention of the discussion in the notes https://github.com/jupyterlab/team-compass/issues/205#issuecomment-1833291448.

The UI-toolkit has been introduced in Jupyterlab in https://github.com/jupyterlab/jupyterlab/pull/15021, and was first admitted in https://github.com/jupyterlab/team-compass/issues/143.

krassowski commented 7 months ago

For context, the discussion started as an off-shoot of a discussion around a release blocker for 4.1 which is tracked in:

I would appreciate a confirmation on what is the plan to address the above issue before I cast my vote.

mbektas commented 7 months ago

It is worth mentioning that we have been using jupyter-ui-toolkit for quite some time in JupyterLab Desktop as well.

ivanov commented 7 months ago

I'm abstaining from the vote, but want to repeat and reframe my earlier sentiment on moving projects to jupyter organizations: can we please provide more justification behind moving projects than just "we are using this"? It's perfectly fine for jupyter project to use libraries that aren't part of the jupyter organizations.

fcollonval commented 6 months ago

I'm abstaining from the vote, but want to repeat and reframe my earlier sentiment on moving projects to jupyter organizations: can we please provide more justification behind moving projects than just "we are using this"? It's perfectly fine for jupyter project to use libraries that aren't part of the jupyter organizations.

I added the following in the top comment:

To provide more background, the toolkit is today in the JupyterLab community organization that is not officially endorsed by Jupyter. So moving it in this organization will ensure official support for maintenance and publication rights. In addition it will allow some members to contribute as they may not be allowed to do so on the community organization due to company policy.

ellisonbg commented 6 months ago

There are a couple of other points that I think would be helpful to understand:

fcollonval commented 6 months ago 
* Can you summarize the status of Fast (the underlying toolkit) and our usage of it. I know Fast itself doing quite a bit of refactoring and would like to understand where all of that is at.

The utilities to create custom elements (aka web components) and handle their rendering lifecycle are being updated. But it does not impact consumers of the toolkit. The current status is unfortunately though to provide as the project as be slow since a year.

* We had tried to use Fast for the Jupyter Scheduler work (just over a year ago) and found it to be poorly documented and difficult to use. Has that been addressed. Has that situation improved?

Fast is an internal dependency of the toolkit. We should not advertise (at least in the short term) the internal tool used by the toolkit. The goal of the toolkit is to provide components on a shell and to consume them either through a framework like React or using vanilla JS. The demo project shows how you can consume the components with vanilla JS or with React. It does not need anything from FAST libraries.

* How mature is the jupyter-ui-toolkit?

It is; see thoses extensions using the vanilla components or the React variant. It is also used in JupyterLab desktop - to highlight its power to be integrated anywhere in the opposite of React only toolkit.

The text of the proposal is ambiguous on this point and sort of suggests that moving it to the JupyterLab org will mean that we are officially endorsing and recommending it for all things Jupyter.

Not for all things in Jupyter (although it would be for the best). But yes for JupyterLab and yes we (the JupyterLab team) are endorsing it by definition of all projects within this org.

* There have been a couple of other situations where we brough new repos in, but believed they were not fully mature and stable (Jupyter AI, pycrdt). In these situations we tagged them (in the README) as being under incubation to help set expectations. Does that make sense here?

It will surely needs changes when more components are used within core. So not problem with tagging it as WIP.