[IPython-dev] Nbparameterise: simple forms for notebook input

[Thomas Kluyver]

Min & I discussed this over lunch today. We think that the way to get the
best of both worlds in form definition is to base the parameters on the
first cell, but supplement them with optional notebook metadata. This will:

- Make the easy cases easy: You can make a basic form from a notebook
without needing to fiddle with metadata.
- Make the hard cases possible: The notebook metadata can be used to
provide extra information for all kinds of applications: display names for
fields, options for multiple-choice parameters, abbreviations for command
line arguments, and so forth.
- Ensure that the notebook can be run without needing the form interface.
We feel this is important, because part of the attraction of notebooks is
that it's easy to run your code and see if you've made a mistake, and you
lose that if your code relies on parameters that have to be set by
machinery outside the notebook.

I have just updated nbparameterise to do this. The example application uses
a display_name field from the metadata to display something nicer than the
variable name as the label for the form field. The API exposes arbitrary
metadata associated with the parameter, from
metadata.parameterise.<variable name>

Thomas

On 10 October 2014 11:02, Thomas Kluyver <takowl at gmail.com> wrote:

> Thanks Ian - conda-launch was one of a few projects that prompted me to
> work on this. In particular, great though conda is, I don't think creating
> forms and executing notebooks should be tied to a particular packaging
> system.
>
> Looking through the description of conda-launch, I think what I want to
> think about most is the different ways of describing the input parameters.
> Conda-launch uses JSON metadata that is potentially more flexible, but very
> distinct from the normal workflow of writing a notebook. Nbparameterise
> currently looks for an initial "definitions cell", which is less
> extensible, but very natural for the notebook author. Part of me wants to
> generalise nbparameterise to handle all possible ways of describing inputs,
> but another part of me wants to hammer out a common way of doing this, so
> notebook authors don't have to learn different things for different
> systems. I'll keep thinking about it.
>
> Best wishes,
> Thomas
>
> On 9 October 2014 18:58, Ian Stokes-Rees <ijstokes at alumni.uwaterloo.ca>
> wrote:
>
>>  FWIW, We (at Continuum) have done some work on something similar,
>> loosely tied to conda:
>>
>> https://github.com/conda/conda-launch
>>
>> It supports 3 modes:
>>
>> 1. CLI invocation of a notebook
>> 2. auto-generated web-form of a notebook
>> 3. RESTful API with URL (GET) or POST-encoded arguments
>>
>> It doesn't require any customization of IPython, and the parameterization
>> can either be in the notebook meta-data, or "inline" if the last cell is a
>> "raw" cell with the appropriate JSON.
>>
>> The parameterization meta-data can also include a set of dependencies, in
>> which case a custom conda-environment will be created in which the notebook
>> will be run.  The goal is to be able to generate notebook output (HTML,
>> data file, figures, return specific serialized references) with no retained
>> state or persisted processes, basically a notebook-based CGI python script.
>>
>> It runs reasonably well right now, but the input form styling is pants
>> (my CSS skills stink!).
>>
>> I haven't had time to read the thread on nbparameterize, but look forward
>> to exploring it next week.  Perhaps the two efforts can be merged.
>>
>> Regards,
>>
>> Ian
>>
>> _______________________________________________
>> 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/20141014/e7018115/attachment.html>