Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split off some parts of coreutils #7615

Closed
vidartf opened this issue Dec 11, 2019 · 5 comments · Fixed by #7681
Closed

Split off some parts of coreutils #7615

vidartf opened this issue Dec 11, 2019 · 5 comments · Fixed by #7681
Assignees
Labels
status:resolved-locked
Milestone

Comments

@vidartf
Copy link
Member

@vidartf vidartf commented Dec 11, 2019

In concert with the major version release of coreutils, we should consider splitting off some parts of the package into new ones.

Pros:

  • Avoid API breaking changes of one part causing consumers of other parts to need to update their dependency/code (or having to add a X || Y semver dependency).
  • We are already moving polling out (to Lumino, see #7598) so now is probably the best time to move other parts as well.

Cons:

  • More packages to manage.
  • More lines of code to change for people updating extensions to lab 2.0.

What to split off

The current exported symbols of coreutils are:

  • ActivityMonitor
  • DataConnector / IDataConnector
  • Debouncer (being moved to Lumino)
  • DefaultSchemaValidator / ISchemaValidator
  • IChangedArgs (pure typings)
  • MarkdownCodeBlocks
  • nbformat
  • PageConfig
  • PathExt
  • Poll / IPoll (being moved to Lumino)
  • RateLimiter / IRateLimiter (being moved to Lumino)
  • RestorablePool (IObjectPool, IRestorable, IRestorer)
  • SettingRegistry / ISettingRegistry / Settings
  • StateDB / IStateDB
  • Text
  • Throttler (being moved to Lumino)
  • Time
  • URLExt

For me the clearest candidates for being split off are the things that export Tokens, namely StateDB and the SettingsRegistry. These are larger components, that would benefit from being semvered independently.

Other candidates:

  • RestorablePool: Similarly to the two above, this is also a larger component. The only difference is that it does not export a Token.
  • Time: moment.js is a big dependency for what is marketed as a "util". See discussions in e.g. #7137
  • nbformat: This could potentially be reused outside of JupyterLab, which would be easier if it was self-contained.
  • PageConfig: Again a larger component that would benefit from independent semver, especially since it also needs to be in sync with the corresponding server component and the protocol they speak.
  • Others?

I would very much like some input on which parts people think makes sense to split off, and which parts to keep in coreutils. We would also need to decide how to redistribute any such parts (move to other packages, make a new package per component, make a new package for some of the components). Note that this is also somewhat time critical to get in before we try to freeze the API for 2.0.

@vidartf
Copy link
Member Author

@vidartf vidartf commented Dec 11, 2019

One issue would also be to consider what this means:

"coreDependency": true

And figure out which if any new packages should be marked similarly.

@blink1073
Copy link
Member

@blink1073 blink1073 commented Dec 11, 2019

Based on the in-person discussions today, I think we should make the following new packages:

  • StateDB
  • SettingsRegistry
  • nbformat

The first two to aid in discoverability since they are token providers, and the last because its API is most likely to evolve over time. I think this strikes a good balance between package number and scope explosion.

@afshin
Copy link
Member

@afshin afshin commented Dec 11, 2019

If StateDB moves, does that mean IDataConnector and DataConnector and the restorable pool stuff should go with it?

SettingRegistry is simpler and totally makes sense to me. Same with nbformat.

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Dec 11, 2019

If we're going to make a new package for nbformat, can we make the name such that moving other validation and message functions from services works too?

For example, serverapi, jupyterapi, jupyterserver, jupyterprotocol, @jupyterlab/protocol, etc.

@vidartf
Copy link
Member Author

@vidartf vidartf commented Dec 12, 2019

If we're going to make a new package for nbformat, can we make the name such that moving other validation and message functions from services works too?

To clarify for readers not in our previous call: @jasongrout is thinking to move some of the code that is part of the service refactor (validation and typings of server API messages) to a separate package for reuse by others. The suggestion seems to be that these live in the same package as nbformat. I think the rationale is that there would be overlap between the contributors to those two parts. Personally, I'm unsure if there would be significant overlap between the users of those two parts.

@lock lock bot added the status:resolved-locked label Jan 24, 2020
@lock lock bot locked as resolved and limited conversation to collaborators Jan 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status:resolved-locked
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants