ipython / ipython/ipykernel

API for identifying overlaying frontend to help libraries interacting with the UI

未關閉
#380 0 則留言 4 個 reaction 已指派 0 人 在 GitHub 檢視
主要語言
Python
星號
734
分支
412
平均合併
1 天 5 小時
30 天內合併 PR
8

描述

Due to this talk
[Discussion about the trial to detect correct renderer in altair](https://github.com/altair-viz/altair/issues/1291)

It would be nice to have information provided for query by an ipykernel-API about the overlaying frontend.

Imagine someone wrote following code in jupyter notebook to visualize something like this:

```
import altair as alt
from vega_datasets import data
cars = data.cars()
alt.renderers.enable('notebook') #jupyter notebook
#alt.renderers.enable('default') #jupyter lab
#dynamic
alt.Chart(cars).mark_point().encode(
x='Horsepower',
y='Miles_per_Gallon',
color='Origin',
)
```
Now the user wants to share the code by his cars.ipynb file.
Another user wants to use it in jupyter lab and wonders why the graph is not shown.
He has again to modify the code, change e.g. 'notebook' to 'default' to make it run.

With an API from ipykernel which is identifying the frontend, the graphic-library could manage the configuration of the renderer by itself to set the optimal renderer and even give a warning when not supported even wrong renderer is used.

In the above link is a proposal hack to identify a frontend, but however, it should be registered in a correct way in the ipykernel.

Maybe someone would like to deal with it or implement that, that would be great!

The implementation of this proposal would mean a much simpler and more dynamic exchange and the faster use of different ipy user interfaces, because the user-code has not to be touched again.

貢獻指南

開啟貢獻指南

研究方向

Start with the linked Altair discussion and the ipykernel API context, then compare the notebook and JupyterLab renderer example in the issue. Done would mean a defined ipykernel API can identify the overlaying frontend so libraries can select a suitable renderer or warn when the current renderer is unsupported.

由索引模型根據 Issue 內容生成。

評估

技術堆疊
jupyter, python
領域
api, backend
Issue 類型
功能
難度
5/5
預估耗時
一週以上
活躍度
停滯
描述清晰度
需要釐清
新手友好度
30/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。