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

TODO/Deprecations for 2.0 #7720

Closed
17 of 23 tasks
jasongrout opened this issue Jan 2, 2020 · 7 comments
Closed
17 of 23 tasks

TODO/Deprecations for 2.0 #7720

jasongrout opened this issue Jan 2, 2020 · 7 comments
Labels
status:resolved-locked
Milestone

Comments

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Jan 2, 2020

Searching the code base for TODO items or deprecations, I see some interesting possibilities:

I put each reference below in a checklist so that we can check off when we have examined it, and we can add a note or reference to an issue if we are solving it now.

Notes about TODO items

Notes about deprecations

  • "SingleUserLabApp is deprecated, use SingleUserNotebookApp and set " + \
  • // Backwards compatibility workaround for services 4.0 defining the wrong
    // comm_info_request content. This should be removed with the deprecated
    // `target` content option in services 5.0. See
    // https://github.com/jupyterlab/jupyterlab/issues/6947
  • // Tests deprecated option workaround. Should be deleted in services 5.0.
  • * A placeholder factory for deprecated rendered JavaScript.
  • * A widget for displaying deprecated JavaScript output.
  • def _ensure_options(options, **kwargs):
    """Helper to use deprecated kwargs for AppOption"""
    optClass = options.__class__ if issubclass(options.__class__, AppOptions) else AppOptions
    # Filter out default-value kwargs
    kwargs = dict(filter(lambda item: item[1] is not None, kwargs.items()))
    # Warn for deprecated kwargs usage
    if kwargs:
    warnings.warn(
    "Direct keyword args to jupyterlab.commands functions are "
    "deprecated, use the options argument instead: %r" % (kwargs,),
    DeprecationWarning)
    if options is None:
    return optClass(**kwargs)
    # Also support mixed use of options and kwargs:
    opt_args = {name: getattr(options, name) for name in options.trait_names()}
    kwargs.update(**opt_args)
    return optClass(**kwargs)
  • # Make sure the deprecated `selenium_check` command still works
@jasongrout jasongrout added this to the 2.0 milestone Jan 2, 2020
@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Jan 2, 2020

@blink1073 - here are some possibly api-breaking changes we've held off on for 2.0. Do you (or anyone else) have time to look at these to decide whether we really want to do them for 2.0?

@jasongrout jasongrout mentioned this issue Jan 2, 2020
25 tasks
@blink1073
Copy link
Member

@blink1073 blink1073 commented Jan 2, 2020

I'm making a PR now, checking off items as I address them.

@telamonian
Copy link
Member

@telamonian telamonian commented Jan 2, 2020

I checked off the one from jupyterlab/packages/filebrowser/src/listing.ts, that's handled by #7700. I'll probably also handle deleting jupyterlab/packages/statusbar/src/deprecated.tsx in that same PR

@blink1073
Copy link
Member

@blink1073 blink1073 commented Jan 2, 2020

I already removed jupyterlab/packages/statusbar/src/deprecated.tsx in my branch.

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Jan 2, 2020

I should add here that the source links above were from looking at the TODO and deprecation search results linked above and trying to filter them for 2.0-relevant issues. If someone has time to look at the full list of search results to double-check that I didn't miss anything relevant, that would be great.

@blink1073
Copy link
Member

@blink1073 blink1073 commented Jan 2, 2020

@telamonian, I see that you would pick up merge conflicts in #7700 if I remove deprecated.tsx, I'll restore it here.

@blink1073
Copy link
Member

@blink1073 blink1073 commented Jan 8, 2020

Closing as addressed by #7724 and #7700, at least as far as 2.0-readiness is concerned.

@lock lock bot added the status:resolved-locked label Feb 8, 2020
@lock lock bot locked as resolved and limited conversation to collaborators Feb 8, 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

No branches or pull requests

3 participants