<div dir="ltr"><div><div><div><div><div>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:<br><br></div>- Make the easy cases easy: You can make a basic form from a notebook without needing to fiddle with metadata.<br></div>- 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.<br></div>- 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.<br><br></div>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><br><br></div>Thomas<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 October 2014 11:02, Thomas Kluyver <span dir="ltr"><<a href="mailto:takowl@gmail.com" target="_blank">takowl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>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.<br><br></div>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.<br><br></div>Best wishes,<br>Thomas<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 9 October 2014 18:58, Ian Stokes-Rees <span dir="ltr"><<a href="mailto:ijstokes@alumni.uwaterloo.ca" target="_blank">ijstokes@alumni.uwaterloo.ca</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
  

    
  
  <div text="#000000" bgcolor="#FFFFFF">
    FWIW, We (at Continuum) have done some work on something similar,
    loosely tied to conda:<br>
    <br>
    <a href="https://github.com/conda/conda-launch" target="_blank">https://github.com/conda/conda-launch</a><br>
    <br>
    It supports 3 modes:<br>
    <br>
    1. CLI invocation of a notebook<br>
    2. auto-generated web-form of a notebook<br>
    3. RESTful API with URL (GET) or POST-encoded arguments<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    It runs reasonably well right now, but the input form styling is
    pants (my CSS skills stink!).<br>
    <br>
    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.<br>
    <br>
    Regards,<br>
    <br>
    Ian<br>
  </div>

<br></div></div><span class="">_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org" target="_blank">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>