[IPython-dev] How to get the notebook name/path in the kernel?

[Stephen Chan]

   We do provenance tracking in the KBase Narrative as well, or rather, we
have an infrastructure to do provenance tracking, but only somewhat early
stage integration with our IPython environment. It might be interesting to
compare notes at some point.

   But back to your original question - the easiest way to do this might be
to bind a front end JS handler to a kernel ready event, and have that push
the notebook name into os.environ['notebook_name']. We do that for some
front end data that needs to get back into the kernel.
   Depending on how you want to track your notebook, maybe you want
something from the JS front end like the value of
IPython.notebook.metadata.name

   So something like this:

    var initEnvironment = function(name,value) {
        try {
            var cmd = "import os\n" +
                      "os.environ['" + name + "'] = '" + value + "'\n";
            IPython.notebook.kernel.execute(cmd, {}, {'silent' : true});
        }
        catch (error) {
            console.log("Doh! It didn't work!");
        }
    };

    $([IPython.events]).one('status_started.Kernel', function() {
        initEnvironment('notebook_name', IPython.notebook.metadata.name);
    });

   I'm not really a JS guru myself, I got this working a few months ago and
prompted swapped JS out of my context, so this might take a little
massaging to make work entirely.

   Steve


On Thu, Feb 27, 2014 at 1:17 AM, Konrad Hinsen
<konrad.hinsen at fastmail.net>wrote:

> Hi Thomas & Fernando,
>
> Thomas Kluyver writes:
>
>  > I don't think there is a good way to get that: the design is
>  > specifically that the kernel is an engine to run code, and should
>  > not know where that code is coming from.
>
> Fernando Perez writes:
>
>  > Konrad, Matthias' recent description is a great one: it's like
>  > asking a book about the color of the eyes of its reader. That
>  > question is fundamentally ill-posed, as multiple people may
>  > simultaneously read a book.
>
> I see your point view, which is that the notebook is just one way of
> interacting with a kernel. Given the I in IPython, that point of view
> is understandable.
>
> My point of view is different because my priority is documenting
> computations. I see a notebook as a document that describes what was
> done and which results were obtained. In the ActivePapers framework, I
> need to know where every bit of executed code comes from, because
> that's an important element in provenance tracking.
>
> A compromise that is compatible with both points of view is putting
> the provenance information for the code in the execute request sent to
> the kernel. This could be a notebook name, but also the process id of
> a qtconsole. It could be different for each execute request, and
> nothing would prevent a single notebook from sending requests to
> multiple kernels.
>
>  > In IPython's case, the same applies: a kernel may be attached to a
>  > notebook, but simultaneously to a terminal and a qtconsole. While
>  > we hold fast on the idea that a notebook should only have *one*
>  > kernel, we've even wondered if it could make sense to have multiple
>  > notebooks connected to an single kernel (to operate on the same
>  > namespace while breaking up the narrative into subdocuments more
>  > conveniently).
>
> >From the "documenting a computation" point of view, that would require
> some clear link between the notebooks that share a kernel. A link that
> remains visible in the resulting notebook files.
>
>  > You can probably write a magic that will call back out from the
>  > kernel to the client JS and fetch the notebook path and would store
>  > it in a variable in the user namespace, but my JS-fu isn't up to
>  > snuff to write that right away. And you'd have to accept that it's
>  > a hack with potentially ambiguous results (if for example we later
>  > allow multiple notebooks to connect to the same kernel).
>
> It looks like I'll need some hack anyway to proceed. If that hack needs
> to be modified in the future, well, that's life on the bleeding edge ;-)
>
> Unfortunately my JS-fu isn't great either, so I'd be grateful for
> suggestions
> from the JS wizards in the audience.
>
> Konrad.
> _______________________________________________
> 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/20140227/2d8ddbc7/attachment.html>