jupyterlab_hubshare

share notebooks on jupyterhub

This extension is composed of a Python package named jupyterlab_hubshare for the server extension and a NPM package named jupyterlab_hubshare for the frontend extension.

Sharing

In general, there will be multiple use case when using jupyterhub:

Requirements

• JupyterLab >= 3.0

Install

pip install jupyterlab_hubshare

Configuration

The extension supports multiple use cases:

Use Case 1: All users on jupyterhub share the same Interface

In this scenario, the path for user A and user B are exactly the same, therefore we only need to configure the URL

c.HubShare.file_path_template = "{path}"

This will make the sharable link looks like http://your.jupyter/user-redirect/?hubshare-preview=path/to/ipynb

if you prefer directly access the file, you can also add:

c.HubShare.use_preview = False

this will make the sharable link looks like http://your.jupyter/user-redirect/path/to/ipynb

but please be aware that this will allow other user directly modify the same file, which should be avoided in most cases.

Use Case 2: User have their own work space but can still access others workspace

This is honestly my preferable settings, for example:

• userA work space: path/workspaces/userA/
• userB work space: path/workspaces/userB/
• but both userA and userB have a shortcut folder links to path/workspaces/ so that they can still check others workspaces.

In this case, you can configure that with:

c.HubShare.file_path_template = "shortcut/{user}/{path}"

This will make the shareable link looks like http://your.jupyter/user-redirect/?hubshare-preview=shortcut/userA/path/to/ipynb (if sharing userA's notebook)

Similarly, you can also set

c.HubShare.use_preview = False

This will make the sharable link looks like http://your.jupyter/user-redirect/shortcut/userA/path/to/ipynb Same as above, be aware that this will allow the other user directly modify the same file!

Use Case 3: User have their own work space, and they are unable to directly reach to others workspace

This is much more like the previous scenario, but there's no shortcut folder to give access to other folder. In this case, you will need to also configure the contents_manager:

c.HubShare.contents_manager = {
    "manager_cls": FileContentManager,
    "kwargs": {
        "root_dir": "path/to/workspaces/
    }
}
c.HubShare.file_path_template = "{user}/{path}"

This will create a sharable link looks like: This will make the shareable link looks like http://your.jupyter/user-redirect/?hubshare-preview=userA/path/to/ipynb (if sharing userA's notebook)

Note that given that the current contents manager doesn't have access to other users workspaces, setting use_preview=False will make invalid link.

Rewrite Shared File Path

In general, you can use file_path_template to provide a easy way to rewrite the shared file path. However, if you want a more complicated rule for path rewrite. You can use file_path_func instead.

def get_share_path(path):
    return f"actual_folder/{path}" if path.startswith("folderA"/) else path

c.HubShare.file_path_func = get_share_path

• You shoud choose either file_path_func or file_path_template. If both set, we will only use file_path_func and ignore file_path_template

Copy link to external sites

Starting 0.3.0, you are now able to copy custom link to any external site. For example, copy the link to github, or some related url. To do so, please add the following config:

c.HubShare.other_link_functions = {
    "github": {
        "label": "github URL",
        "path_func": lambda path: f"https://github.com/test/repo/{path}"
    },
    "view-only": {
        "label": "other URL",
        "path_func": lambda path: f"http://example.com/prefix/{path}"
    }
}

• the dict key is just an identifiable ID so that we are able to find the correct path_func to update. You can use anything
• label is the actul item visible on your context. It will be shown as "Copy {LABEL}".
• path_func is a function that takes path as argument, and return the expected url to create

Troubleshoot

If you are seeing the frontend extension, but it is not working, check that the server extension is enabled:

jupyter server extension list

If the server extension is installed and enabled, but you are not seeing the frontend extension, check the frontend extension is installed:

jupyter labextension list

Contributing

Development install

Note: You will need NodeJS to build the extension package.

The jlpm command is JupyterLab's pinned version of yarn that is installed with JupyterLab. You may use yarn or npm in lieu of jlpm below.

# Clone the repo to your local environment
# Change directory to the jupyterlab_hubshare directory
# Install package in development mode
pip install -e .
# Link your development version of the extension with JupyterLab
jupyter labextension develop . --overwrite
# Rebuild extension Typescript source after making changes
jlpm run build

You can watch the source directory and run JupyterLab at the same time in different terminals to watch for changes in the extension's source and automatically rebuild the extension.

# Watch the source directory in one terminal, automatically rebuilding when needed
jlpm run watch
# Run JupyterLab in another terminal
jupyter lab

With the watch command running, every saved change will immediately be built locally and available in your running JupyterLab. Refresh JupyterLab to load the change in your browser (you may need to wait several seconds for the extension to be rebuilt).

By default, the jlpm run build command generates the source maps for this extension to make it easier to debug using the browser dev tools. To also generate source maps for the JupyterLab core extensions, you can run the following command:

jupyter lab build --minimize=False

There's also a quick target in Makefile:

make venv

build the workspace

make build

build the package

make watch

to quickly develop with jupyterlab

make jupyterhub

to test the share function in jupyterhub

Uninstall

pip uninstall jupyterlab_hubshare