data_transformers not working in Jupyterlab

[malramsay64]

There is an issue with using the data transformers in the latest version of Juptyerlab (1.0.5) resulting in the error 403 GET /files/?_xsrf=2|572196ba|42fbfea4f325901e3948cbc75bd747c8|1565583318/altair-data-6572fe4ca88650e09d67c52dd6a94b8a.json (172.17.0.1): is not a file

The problem seems to be in the GET request, which has the _xsrf information before the file information. Using the dev tools to edit and resend the request either the removal of the _xsrf parameter from the url, or moving it after the filename results in a successful request.

I realise this is probably not an issue with altair, however I don't know which would be the most suitable repository.

The code to reproduce is below, which can be run in a new environment (I have also tried docker container) using

conda create -n jupyter-test jupyterlab==1.0.5 altair==3.2.0 pandas==0.25.0

import altair as alt
import pandas as pd
from pprint import pprint
alt.data_transformers.enable("json")
df = pd.DataFrame({"x": [1,2,3], "y": [1,2,3]})
alt.Chart(df).mark_line().encode(x="x", y="y")

[premopie]

Hello,

I can acknowledge this issue too. I am using

jupyter core     : 4.5.0
jupyter-notebook : 6.0.0
qtconsole        : 4.5.2
ipython          : 7.7.0
ipykernel        : 5.1.2
jupyter client   : 5.3.1
jupyter lab      : 1.0.5
nbconvert        : 5.6.0
ipywidgets       : 7.5.1
nbformat         : 4.4.0
traitlets        : 4.3.2

Any chart created with the json data transformer (for instance example given below)

import altair as alt
alt.data_transformers.enable('json')

from vega_datasets import data

iris = data.iris()

alt.Chart(iris).mark_point().encode(
    x='petalLength',
    y='petalWidth',
    color='species'
)

results with empty chart and Jupyter Lab outputs

[W 12:16:19.141 LabApp] 403 GET /files/?_xsrf=2|4dcde5bd|4230da5b2a3063af50a4783dc3711fa1|1565593020/altair-data-00726f67adaf49ae64cd6a83766a62d8.json (::1):  is not a file
[E 12:16:19.169 LabApp] Could not open static file ''
[W 12:16:19.170 LabApp] 403 GET /files/?_xsrf=2|4dcde5bd|4230da5b2a3063af50a4783dc3711fa1|1565593020/altair-data-00726f67adaf49ae64cd6a83766a62d8.json (::1) 30.47ms referer=http://localhost:8888/lab
[W 12:16:19.225 LabApp] 403 GET /files/?_xsrf=2|4dcde5bd|4230da5b2a3063af50a4783dc3711fa1|1565593020/altair-data-00726f67adaf49ae64cd6a83766a62d8.json (::1):  is not a file
[W 12:16:19.227 LabApp] 403 GET /files/?_xsrf=2|4dcde5bd|4230da5b2a3063af50a4783dc3711fa1|1565593020/altair-data-00726f67adaf49ae64cd6a83766a62d8.json (::1) 3.40ms referer=http://localhost:8888/lab

in the console.

[jakevdp]

Thanks for the report. I'm not certain we can support this change of behavior in the jupyterlab frontend. I'd suggest raising an issue with Jupyterlab, and in the meantime no using the json transformer.

[jasongrout]

The change in jlab came from jupyterlab/jupyterlab#6985

How is altair using the manager.services.contents.getDownloadUrl function? Is it trying to manually append a path after it (it shouldn't if it is).

[jakevdp]

Altair doesn't use any jupyterlab-specific functionality: my understanding is that the Jupyter ecosystem is designed such that the backend must be agnostic to the frontend, so as JupyterLab's frontend diverges from Jupyter Notebook's frontend, packages that require nontrivial frontend-side logic will have to choose which to support and which to drop.

[jakevdp]

I think the best option to fix this from the altair side would be to create a json_jupyterlab version of the json transformer that works with JupyterLab's frontend file server.

[jasongrout]

Actually it looks like the problem is in the Vega plugin for jlab. I posted some comments on the JLab issue.

[jakevdp]

Which jupyterlab issue? I don't see any additional comments at the link above.

[jasongrout]

jupyterlab/jupyterlab#7017

[jasongrout]

It was an automatic reference above

[jakevdp]

OK, great. I'm not familiar with the JupyterLab vega extension – is it a straightforward fix?

[jakevdp]

On the Altair side, the JSON extension is placing a file in the current directory and assuming it is accessible from the frontend as a relative url ("data": "filename.json" within the vega-lite spec).

[jasongrout]

Thanks for the explanation. That should work for most cases.

[jasongrout]

OK, great. I'm not familiar with the JupyterLab vega extension – is it a straightforward fix?

It should be. Basically it was asking for a download URL for the current path, and assuming that it could treat that like a base path, so it wasn't stripping off query parameters, etc. It should strip off the query parameters before assuming it can use it as a base url.

[jasongrout]

Okay, this should be fixed in jupyterlab/jupyterlab#7022.