Integrate with IRdisplay

Issue #239 new
Thomas Kluyver
created an issue

When writing the R kernel for IPython, I split out the display part as a separate package, IRdisplay, so that the R kernel and the R magic could use the same API to display rich objects to IPython.

To integrate with this, you need to assign a base_display(data, metadata) function into the IRdisplay namespace, which will send a display_data message. The other functions in IRdisplay call this to do their work. If this API doesn't work for the R magic, let me know, and we can work something out.

Assigning into another package is a bit awkward in R, but it is possible; this is what the R kernel currently does:

  display  = function(data, metadata=NULL) {
    if (is.null(metadata)) {
        metadata = namedlist()
    }
    send_response("display_data", request, 'iopub',
            list(source='R display func', data=data, metadata=metadata)
        )
    invisible(T)
  }

  # Push the display function into the IRdisplay namespace
  # This looks awkward, but we do need to get a reference to the execution
  # state into a global environment.
  unlockBinding("base_display", displayenv)
  assign('base_display', display, pos=displayenv)

For the R magic, the function can probably be a reference to the publish_display_data function in Python.

Comments (9)

  1. Thomas Kluyver reporter

    I would imagine that it would skip this if IRdisplay was not installed, i.e. the equivalent of this code (if IRdisplay were a Python package instead of an R package):

    try:
        import IRdisplay
    except ImportError:
        pass
    else:
        IRdisplay.base_display = IPython.display.publish_display_data
    
  2. Laurent Gautier

    I don't know...

    The idea of having a common code base for display is seducing but it would go against the "only Python needed" for customizing rpy2's behavior (and the reliance on an R package not shipping with R for the most basic functionalities an almost automatic stream of complains from rpy2 users).

  3. Dav Clark

    @Thomas Kluyver, it seems like perhaps the missing R dependency could be handled in IRdisplay? I'm also quite confused about why python code is needed for an R kernel. Does IRkernel require a python notebook server?

    Let's talk about this on Friday at the Python Work Party?

  4. Thomas Kluyver reporter

    @Laurent Gautier: I should have made that clearer. I'm suggesting that the R magic integrate with IRdisplay if it's installed in R, not that it should require IRdisplay. The user can install it if they want to display rich output, while standard text output and plots will continue to work without it.

    @Dav Clark: Sorry, that was a confusing example. IRdisplay is an R package. The Python code sample was really pseudocode to explain the nature of what I'm suggesting - the real code would be the equivalent operations to load and manipulate an R package through rpy2. I don't know exactly how that would work, so I wrote pseudocode by pretending that IRdisplay was a Python package.

  5. Laurent Gautier

    Late follow-up. Does this still look like a candidate solution ? ipython/jupyter is a moving target, I am happy to keep that opened but also happy to close it if no longer relevant.

  6. Thomas Kluyver reporter

    I think this is still relevant and a sensible thing to do. IRkernel still uses IRdisplay, IRdisplay is not changing very fast, so it should be safe to target, and it would make a more common experience between IRkernel and the %%R magic.

    I'm not really using R these days, though, so working on this is not high on my priority list.

  7. Dav Clark

    I have been shifting gears more towards actually doing some coding, as I'm preparing for a move east to Kennedy Krieger / Hopkins School of Med. So, maybe now is a good time to rope myself into making some small improvements here.

    That said, it strikes me that having redundant code paths for display is worse than the current situation - we'd need to maintain the python code in any case, and then integration with IRdisplay on top of that. So, I'd vote against supporting both options unless IRdisplay solves some issues that rpy2 has, e.g., #125 or #252.

    I'm actually planning on switching to a windows laptop and probably doing more with R again in the near future, so my skin in the game will be on an upward trajectory (of late, I've been more like Thomas - no real use of R in any context...).

  8. Laurent Gautier

    (...)

    That said, it strikes me that having redundant code paths for display is worse than the current situation - we'd need to maintain the python code in any case, and then integration with IRdisplay on top of that. So, I'd vote against supporting both options unless IRdisplay solves some issues that rpy2 has, e.g., #125 or #252.

    I was thinking that may be there would be a way to dip a toe first by managing to reroute the current display of R objects. It might require a bit of refactoring in rmagic though (and there is also code to render objects in the notebook in rpy2.ipython.html and rpy2.ipython.ggplot)

    I'm actually planning on switching to a windows laptop and probably doing more with R again in the near future, so my skin in the game will be on an upward trajectory (of late, I've been more like Thomas - no real use of R in any context...).

    If rpy2 + windows, there is a bit to do at the C-level to be on par with the Linux/OS X versions. May be you'll find #284 the fastest path to productivity.

    Regarding the use of R, if you are working with data in a tabular format and need transform that table and make figures, I'd say that ggplot2 and dplyr might be part of your standard toolbox after you try them (the later can also handle remote tables in SQL). I gave a recent tutorial showcasing them at a Jupyter Days Boston: https://github.com/lgautier/jpd-pdapr-slides

  9. Log in to comment