-
Notifications
You must be signed in to change notification settings - Fork 17
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
Allow mounting jupyterlite content #49
Conversation
What's remaining in this PR: If |
Or maybe the other way around? The |
Right! I'll check how to do that. We may want to let the user overwrite this behavior if needed. |
7dcea9a
to
e0657b1
Compare
jupyterlite_xeus/add_on.py
Outdated
None, | ||
allow_none=True, | ||
config=True, | ||
description="Whether or not to mount the jupyterlite content into the kernel. This allows bypassing the file-system core JupyterLite implementation.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it completely bypass, or does it provide a way to bundle additional files at build time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Answering my own question after checking the code below: it does seem to bypass:
if (await this._remote.isDir('/files')) {
await this._remote.cd('/files');
} else if (options.mountDrive) {
await this._remote.cd(localPath);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe something we could add to the docs once we have #17.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it completely bypass, or does it provide a way to bundle additional files at build time?
You can still provide extra mount points 👍🏽 It's just that now jupyterlite-xeus has an extra mount point /files
that contains the jupyterlite content.
Answering my own question after checking the code below: it does seem to bypass:
No it does not. The service worker is still enabled. So if you do an os.chdir
into the mount point of the service worker based filesystem, you'd be using that.
The code you pointed to is only changing the cwd from where the kernel is starting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed it would be nice to clarify all this in proper documentation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jtpio I updated the description to be a bit more clear
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah ok, thanks for the extra context 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Thank you! Let's work on some proper documentation |
cc. @trungleduc @DerThorsten @jtpio
This allows optionally mounting the jupyterlite content into the kernel.