[IPython-dev] Questions on implementing some notebook frontend extensions

Sat Mar 7 17:22:08 EST 2015

Agreed. In my mind, this is something that can be done as part of the
kernel.

For example, kernelspec.json can specify a list of formats that the kernel
accepts as import and export; then messages in the messaging spec can be
used to transmit notebook data forward and backward. Trying to make
nbconvert or nbconvert wrappers do everything is an infinite problem -- you
could instead delegate this to the kernels themselves. This would allow
kernels to take all of this effort onto themselves.

Anyway, it's clear that there's some design work to be done here. I'm happy
to discuss this further when things come around to it :)

-- Andrew

On Sat, Mar 7, 2015 at 1:44 PM, MinRK <benjaminrk at gmail.com> wrote:

>
>
> On Sat, Mar 7, 2015 at 1:23 PM, Andrew Gibiansky <
> andrew.gibiansky at gmail.com> wrote:
>
>> Thanks Min! That's exactly the sort of feedback I was hoping to get.
>>
>> To respond to your question about what I've found lacking, my main
>> desires for additions to IPython are for a better import and export story
>> for kernels. Specifically, right now IPython supports the following exports:
>>
>>    - txt
>>    - PDF via latex
>>    - Markdown
>>    - HTML
>>
>> These are all well and good, but they're not enough. In my experience,
>> the formats used vary by technology and community, and thus need to be
>> someone more flexible. Specifically, in the Haskell world, we at least
>> would want the following:
>>
>>    - Import from literate Haskell (two different types of literate
>>    haskell)
>>    - Export to literate Haskell (two different types)
>>    - Export to a Haskell module (which would require some processing to
>>    make the cells actually valid compilable Haskell code)
>>    - Export to a cabal package (which would be like exporting to a
>>    Haskell module, but with more postprocessing)
>>
>> These are things that are pretty integral to the Haskell ecosystem, and
>> so it would make sense to ship them with the IHaskell kernel, and not as
>> some sort of extensions. That said I totally understand why these don't
>> exist (yet) -- there's tons of stuff going on in the IPython world and
>> there's not enough developer manpower to do *everything, *but I do hope
>> that going forward to 3.1 or 4 or whatever is next, there might be some
>> design work put into a more compelling configurable import/export story.
>>
>
> It is clear that there are changes that need to be made in nbconvert. I
> was just talking with Jess Hamrick yesterday about some of the changes we
> should make for nbgrader, another of the more demanding nbconvert use
> cases, revealing problems in how nbconvert is put together.
>
> I don't think nbconvert on its own is going to cover quite everything you
> described. For instance, the cabal package export might be a separate tool
> that *uses* nbconvert, rather than being implemented as a highly configured
> invocation of nbconvert itself. And fully custom templates that don't match
> any of the pre-installed formats are possible right now, but it's not at
> all clear how to use them, and both how we communicate that, and how they
> actually work need to be improved.
>
> It is super helpful to have as many use cases as we can get, even if our
> answer to some of them is "that's best done with a separate tool that wraps
> nbconvert," we can still make changes in nbconvert to facilitate these
> things.
>
> -MinRK
>
>
>
>>
>> -- Andrew
>>
>> On Sat, Mar 7, 2015 at 12:17 PM, MinRK <benjaminrk at gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Mar 6, 2015 at 11:50 PM, Andrew Gibiansky <
>>> andrew.gibiansky at gmail.com> wrote:
>>>
>>>> Hey all,
>>>>
>>>> I have a few frontend modifications I'd like to make for the IHaskell
>>>> kernel, and I'd love to get some pointers on where to start and how
>>>> feasible these are. I have some ideas, but since you are much more familiar
>>>> with the client-side JS than I am, I'd like to hear if you think these are
>>>> possible and/or reasonable, and perhaps how you would approach them (no
>>>> detailed response required, maybe just something like "Use the CodeMirror
>>>> api" or "we have some undocumented capabilities for this in IPython" or
>>>> "wait until CodeMirror 5" or "impossible").
>>>>
>>>> The extensions are:
>>>>
>>>> 1. Get some info about an identifier from the kernel when I hover my
>>>> mouse over that identifier, and display it as a popup.
>>>>
>>>> Idea: Use CodeMirror API and IPython comms to communicate with kernel.
>>>>
>>>
>>> I think CM.coorsChar is the relevant API.
>>>
>>> You might not need to use comms for this one, if `inspect_request` is
>>> the right action. If the output should be distinguished from inspection via
>>> other means, then a custom comm would be appropriate.
>>>
>>>
>>>>
>>>> 2. Add a keyboard shortcut to automatically reformat a cell, and have
>>>> this actually change the contents of whichever cell is currently selected,
>>>> provided it is a Haskell cell.
>>>>
>>>> Idea: Use the IPython API to add a keyboard shortcut, use comms to
>>>> communicate with backend to do reformatting, use IPython API to get
>>>> currently selected cell and send contents to kernel via comm, and  use
>>>>  IPython APIs to change the contents of a cell.
>>>>
>>>
>>> Sounds right to me.
>>>
>>>
>>>>
>>>> If you have any suggestions for better routes, words of caution, I'd
>>>> love to hear them.
>>>>
>>>> (As an aside, one reason I am asking like this rather than just going
>>>> ahead and trying it and seeing how far I get is that some of these may be
>>>> tackled by some other contributors to IHaskell; I would like to make sure I
>>>> am not sending them off on a wild goose chase with a method that is
>>>> overcomplicated or unlikely to work before giving them instructions.)
>>>>
>>>
>>> I see no geese here to chase.
>>>
>>>
>>>>
>>>> Thanks!
>>>> Andrew
>>>>
>>>> PS. IHaskell `master` now supports IPython 3.0. There's still a bit of
>>>> work to be done before I'm ready to make a Jupyter-ready *release*, but it
>>>> is no more than a week or two out. So far, I've really enjoyed working with
>>>> IPython 3; the interface is great, the kernel interface is well thought out
>>>> (if perhaps missing a few things I want, but there's always room for
>>>> extension, I hope :) ), and all in all it's been very good.
>>>>
>>>
>>> Great to hear that 3.0 is working out for you. Can you describe the
>>> missing things? It may be a while before there's another revision, but it's
>>> good to keep track of what shortcomings kernel authors find, so we can make
>>> the right adjustments in the future.
>>>
>>> -MinRK
>>>
>>>
>>>>
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150307/29d29480/attachment.html>