Jupyter Notebook Previewer

[JR-1991]

Jupyter notebooks are widely used in our community, but there hasn’t been a previewer for them yet, aside from a full Binder run. This pull request introduces a Jupyter Notebook previewer to the Dataverse external tools ecosystem, allowing users to view .ipynb files directly in the browser with syntax highlighting, markdown support, and mathematical expression rendering. In addition to typical Python, this previewer also utilizes Prism to provide syntax highlighting for Julia and R.

Jupyter Notebook Previewer Integration

• Added a new external tool registration example for the Jupyter Notebook previewer in both 5.2curlcommands.md and 6.1curlcommands.md documentation files, detailing its usage and API parameters. [1] [2]

Frontend Implementation

• Introduced previewers/betatest/JupyterPreview.html, a standalone HTML page that loads required libraries (Prism.js, marked.js, notebookjs, KaTeX, Bootstrap) and custom scripts/styles to render Jupyter notebooks with syntax highlighting, markdown, and math support.
• Added previewers/betatest/js/jupyter.js, which configures notebook rendering, syntax highlighting, and handles the loading and display of notebook content.
• Created previewers/betatest/css/jupyter.css for custom styling of notebook cells, headings, tables, and outputs to mimic the Jupyter Notebook look and feel.

Internationalization

• Updated English, Spanish, and French translation files to include the jupyterPreviewText key for multi-language support of the previewer interface. [1] [2] [3]

Local tests

I’ve tested this previewer on a locally hosted Dataverse 6.6 container. I’ve been testing older releases in parallel, so the older release is being used here. However, I don’t think this will affect newer versions. I have used the following manifest:

{
    "displayName":"Show Jupyter Notebook",
    "description":"View the Jupyter Notebook file.",
    "toolName":"jupyterPreviewer",
    "scope":"file",
    "types":["preview"],
    "toolUrl":"http://localhost:8000/JupyterPreview.html",
    "toolParameters": {
        "queryParameters":[
          {"fileid":"{fileId}"},
          {"siteUrl":"{siteUrl}"},
          {"datasetid":"{datasetId}"},
          {"datasetversion":"{datasetVersion}"},
          {"locale":"{localeCode}"},
          {"key":"{apiToken}"}
        ]
      },
    "contentType":"application/x-ipynb+json"
  }

Screenshots

Draft View

Published View

Full View

Code and Viz Example

[qqmyers]

@JR-1991 - Cool!. Not sure I understand what you're asking about signed urls: When using retriever.js, and using writeContentAndData() in your js, both forms are automatically supported. The only change required is to change the configuration json. In general, I think we've been putting the old form in the 5.2 curl commands (prior to signed urls) and using the signed url form in the 6.1+ examples.

For signed URLs, using retriever.js, you have to add URLs retriever.js expects - as in

dataverse-previewers/6.1curlcommands.md

Lines 25 to 44 in a7472ad

	"allowedApiCalls": [
	{
	"name": "retrieveFileContents",
	"httpMethod": "GET",
	"urlTemplate": "/api/v1/access/datafile/{fileId}?gbrecs=true",
	"timeOut": 3600
	},
	{
	"name": "downloadFile",
	"httpMethod": "GET",
	"urlTemplate": "/api/v1/access/datafile/{fileId}?gbrecs=false",
	"timeOut": 3600
	},
	{
	"name": "getDatasetVersionMetadata",
	"httpMethod": "GET",
	"urlTemplate": "/api/v1/datasets/{datasetId}/versions/{datasetVersion}",
	"timeOut": 3600
	}
	]

(you can see the names for these URLs are hardcoded at

dataverse-previewers/previewers/betatest/js/retriever.js

Lines 43 to 51 in a7472ad

	switch (url.name) {
	case 'retrieveFileContents':
	queryParams.fileUrl = url.signedUrl;
	break;
	case 'downloadFile':
	queryParams.fileDownloadUrl = url.signedUrl;
	break;
	case 'getDatasetVersionMetadata':
	queryParams.versionUrl = url.signedUrl;

). (I don't think the tool parameters are used at all with signed Urls, but we generally haven't removed them from the example curl calls.)

[JR-1991]

@qqmyers, thanks for clarifying and providing the snippets. I was only looking at the lower part implementing the previous mechanism, but that’s fantastic to know! I’ll add the allowedApiCalls and open it for review.