Permission Denied error when invoking show() from inside Jupyter Notebook

Hi,

I’m using bokeh 0.12.3 and jupyter 1.0.0. I’m writing some code that produces a simple bar chart and calls show() on this bar chart inside the notebook.

Here’s the backtrace that I get:

PermissionError                           Traceback (most recent call last)
<ipython-input-3-e94210215dfe> in <module>()
      1 results = r._get_results()
----> 2 v.visualize(results, None, None)

/home/lukas/src/tcpsp/TCPSPsuite/scripts/visualizer.py in visualize(self, results, x_axis, y_axis)
     11         chart = Bar(df, 'job_count', values='elapsed', agg='mean')
     12 
---> 13         show(chart)

/home/lukas/.virtualenvs/tcpsp/lib/python3.5/site-packages/bokeh/io.py in show(obj, browser, new, notebook_handle)
    312     if obj not in _state.document.roots:
    313         _state.document.add_root(obj)
--> 314     return _show_with_state(obj, _state, browser, new, notebook_handle=notebook_handle)
    315 
    316 

/home/lukas/.virtualenvs/tcpsp/lib/python3.5/site-packages/bokeh/io.py in _show_with_state(obj, state, browser, new, notebook_handle)
    330 
    331     if state.file or not shown:
--> 332         _show_file_with_state(obj, state, new, controller)
    333 
    334     return comms_handle

/home/lukas/.virtualenvs/tcpsp/lib/python3.5/site-packages/bokeh/io.py in _show_file_with_state(obj, state, new, controller)
    335 
    336 def _show_file_with_state(obj, state, new, controller):
--> 337     filename = save(obj, state=state)
    338     controller.open("file://" + filename, new=_new_param[new])
    339 

/home/lukas/.virtualenvs/tcpsp/lib/python3.5/site-packages/bokeh/io.py in save(obj, filename, resources, title, state, validate)
    394 
    395     filename, resources, title = _get_save_args(state, filename, resources, title)
--> 396     _save_helper(obj, filename, resources, title, validate)
    397     return os.path.abspath(filename)
    398 

/home/lukas/.virtualenvs/tcpsp/lib/python3.5/site-packages/bokeh/io.py in _save_helper(obj, filename, resources, title, validate)
    462         html = standalone_html_page_for_models(obj, resources, title)
    463 
--> 464         with io.open(filename, "w", encoding="utf-8") as f:
    465             f.write(decode_utf8(html))
    466 

PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.5/runpy.html'

It seems like I’m not the only one experiencing the problem: see for example https://github.com/yhat/rodeo/issues/211

I’m pretty sure the problem is in _detect_filename() in io.py: If no filename to save a chart to is supplied, it tries to save the file (with an autodetected filename) into the directory of the currently executing file (more exactly: the file executing in the topmost stackframe, which is assumed to be the main file being run.) This fails spectacularly if that file is located in a read-only location as is the case when you run an jupyter notebook, which on my system seems to use “/usr/lib/python3.5/runpy.py” to run the notebook.

I think the cleanest solution would be to use a temporary directory if no save-to directory is specified. If no directory is specified, the user is probably not really interested in the file, but only needs it temporarily: This happens in the show() method, for example.

Is there a reason for saving temporary files in the directory of the script? In that case, should the save() method be amended by a “temporary” argument (with default False), which in turn tells _detect_filename() to use a temporary directory? In that case, show() could set that flag and avoid the permission problem…?

I’d be willing to cook up a pull request if I get any feedback on how you think this problem should be solved.

[bryevdv]

@tinloaf A PR would be appreciated, are you still interested in working on one?

My personal preference would just be to always use a writable temp file. I think the observation that if someone is calling show without output_file, they they probably just want to see the result in a browser, and don’t really care about a file, is correct. I think that behavior would actually fill in a capability gap that currently exists. This approach would also be simple to implement, explain, and avoid magic.

@mattpap @almarklein does that sound ok? I think wanting show to “just work” i.e. open a browser with the output without a filename is reasonable. But I also think if you do want the file, it is not too much to require that the filename be specified to mark that interest (i.e. with output_file).

[jsignell]

@bryevdv I see now.