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

Derive jupytext cm from app cm #275

Merged
merged 4 commits into from
Jul 6, 2019
Merged

Conversation

mwouts
Copy link
Owner

@mwouts mwouts commented Jun 30, 2019

Jupytext's CM is derived directly from the NotebookApp (or ServerApp)'s contents manager.
This should allow Jupytext to be used with Voila - see #270
(@SylvainCorlay, what else do we need to do for this?)

@mwouts
Copy link
Owner Author

mwouts commented Jun 30, 2019

@153957, @fool65c, when this gets ready I will prepare a release candidate and make sure you can test it, as you reported using a CM derivated from Jupytext's TextFileContentsManager...

@codecov
Copy link

codecov bot commented Jun 30, 2019

Codecov Report

Merging #275 into master will increase coverage by <.01%.
The diff coverage is 98.17%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #275      +/-   ##
==========================================
+ Coverage   99.19%   99.19%   +<.01%     
==========================================
  Files          68       68              
  Lines        6612     6617       +5     
==========================================
+ Hits         6559     6564       +5     
  Misses         53       53
Impacted Files Coverage Δ
jupytext/__init__.py 100% <100%> (ø) ⬆️
jupytext/version.py 100% <100%> (ø) ⬆️
jupytext/contentsmanager.py 98.44% <98.14%> (+0.01%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 12c7dea...a89d2b0. Read the comment docs.

@lgtm-com
Copy link

lgtm-com bot commented Jun 30, 2019

This pull request introduces 1 alert when merging 04894ff into 872c658 - view on LGTM.com

new alerts:

  • 1 for Unused import

@153957
Copy link
Contributor

153957 commented Jul 2, 2019

Thanks for the heads up, I will have a look.

@mwouts mwouts force-pushed the derive_jupytext_cm_from_app_cm branch from 04894ff to 611c7e2 Compare July 3, 2019 05:52
@mwouts
Copy link
Owner Author

mwouts commented Jul 3, 2019

There is a release candidate for this:

pip install jupytext==1.2.0rc1

@153957, @fool65c, could you please test that this is compatible with your own content manager?

Also, I would be curious to know whether this would work:

from jupytext.contentsmanager import build_jupytext_contents_manager_class
c.NotebookApp.contents_manager_class = build_jupytext_contents_manager_class(base_cm_class)

where base_cm_class if your base cm class (in case you have one that is not based on the Jupytext cm).

@lgtm-com
Copy link

lgtm-com bot commented Jul 3, 2019

This pull request introduces 1 alert when merging 611c7e2 into 12c7dea - view on LGTM.com

new alerts:

  • 1 for Unused import

@fool65c
Copy link
Contributor

fool65c commented Jul 3, 2019

@mwouts I was able to test and it worked as expected thanks for pushing it through

@153957
Copy link
Contributor

153957 commented Jul 4, 2019

It correctly detects my custom class being a subclass. and seems to work fine.

I also tried

from jupytext.contentsmanager import build_jupytext_contents_manager_class
c.NotebookApp.contents_manager_class = build_jupytext_contents_manager_class(base_cm_class)

And made my base_cm_class a subclass of LargeFileManager, however, I then ran into some issues like Config option 'default_jupytext_formats' not recognized by 'base_cm_class'. It did seem to use my custom class: Deriving a JupytextContentsManager from base_cm_model. So that seems to happen in the wrong order.

@mwouts
Copy link
Owner Author

mwouts commented Jul 4, 2019

Thanks @fool65c and @153957 , it's great that you could test this. Thank you so much!

however, I then ran into some issues like Config option 'default_jupytext_formats' not recognized by 'base_cm_class'. It did seem to use my custom class: Deriving a JupytextContentsManager from base_cm_model. So that seems to happen in the wrong order.

Interesting. The message Deriving a JupytextContentsManager from base_cm_model is printed by Jupytext's server extension. But this should only occur when the notebook app's contents manager is not already supercharged with Jupytext's one. Maybe I could have been clearer - my question was whether something like the below in your jupyter_notebook_config.py does work (it does locally here):

from jupytext.contentsmanager import build_jupytext_contents_manager_class
from notebook.services.contents.largefilemanager import LargeFileManager


class UserSpecificContentsManagerClass(LargeFileManager):
    """A CM defined by the user"""
    pass


c.NotebookApp.contents_manager_class = build_jupytext_contents_manager_class(UserSpecificContentsManagerClass)
c.ContentsManager.default_jupytext_formats = "ipynb,md"

@lgtm-com
Copy link

lgtm-com bot commented Jul 4, 2019

This pull request introduces 1 alert when merging a89d2b0 into 9bda1f8 - view on LGTM.com

new alerts:

  • 1 for Unused import

@mwouts
Copy link
Owner Author

mwouts commented Jul 6, 2019

With the latest commit I now see the server extension setting Jupytext's contents manager on Jupyter Server:

(python3) C:\Users\Marc\Documents\GitHub\jupytext>jupyter server
[I 21:12:47.182 ServerApp] [Jupytext Server Extension] Deriving a JupytextContentsManager from LargeFileManager
[I 21:12:47.183 ServerApp] Serving notebooks from local directory: C:\Users\Marc\Documents\GitHub\jupytext
[I 21:12:47.183 ServerApp] The Jupyter Server is running at:
[I 21:12:47.183 ServerApp] http://localhost:8888/?token=...

So I think we're good to go!

@mwouts mwouts merged commit 4693c50 into master Jul 6, 2019
@mwouts mwouts deleted the derive_jupytext_cm_from_app_cm branch July 6, 2019 19:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants