Papermill: Introspect Parameters before Execution

[teddyrendahl]

Question

I was curious if there was a way to introspect the default parameters of a Notebook before execution. I see that if I execute_notebook with parameters I can then read these afterwards, but I can't ask what they are before-hand.

Implementation

Would it be appropriate to catch this during the load_notebook_node function? We could capture this as a "default_parameters" in the nb.metadata? Happy to put in a PR if this seems useful to anyone else.

https://github.com/nteract/papermill/blob/81af3f3807674d4ca651a66a29eb9b095a411da7/papermill/iorw.py#L213

[MSeal]

Hi @teddyrendahl !

We would definitely love some contributions on the topic. Here's a PR that started this effort which I hadn't gotten around to picking up again: https://github.com/nteract/papermill/pull/158. Updating that PR or making a new one based on it would be very much welcomed. The idea was to have a notebook inspector object that tried best-effort attempts to parse the input parameters and generate a list of optionally type, optionally docstringed input parameters by using the built-in translator objects to parse the parameter tagged cell.

The final goal was to enable both notebooks as a CLI command (with auto-generated help strings) and to allow other interfaces to promote the parameters for a notebook without redefining them outside the notebook. So the PR is labeled for the first effort but the second effort was exactly what you were asking for I think.

[MSeal]

I hadn't thought about populating the notebook metadata. That might be a nice way to communicate to external systems. What schema were you thinking for storing this information in the nb.metadata?

[teddyrendahl]

Wow! #158 looks like quite the first strike. I was thinking of something a little simpler to start. I was just thinking about putting it in nb.metadata['papermill']['default_parameters']?

I think the challenging part would be differentiating between a Notebook that has been executed with past parameters (i.e not default) and that which has not been executed and are configurable by the user.

[MSeal]

Well the injected parameters are tagged on injected-parameters and the defaults are always parameters (or missing) so you can differentiate between the two safely now.

[teddyrendahl]

Didn't see that change 👍

[puma314]

This is somewhat related, but say that within our notebook we have

a = 6 
b = 7
c = int(open('num.txt', 'r').read()) # c=8

within our parameters cell. Then running

pm.execute_notebook('input_notebook.ipynb', 'output_notebook.ipynb', dict(a=6, b=7, c=8))

will throw an error if num.txt is not present--which might be the case if the environment you're running the papermill command is different than the local jupyter notebook environment. This seems related to introspecting parameters before executing, because I can imagine programmatically commenting out lines in the parameters cell that are declaring parameters that are being passed in through the papermill parameters argument to avoid this problem.

[MSeal]

Hmm possibly. It might not be the prerogative of papermill to determine this. When we use this type of pattern we tend to resolve raw data transformations post parameters. Such that we'd have

c_source = 'num.txt'
c = None

in the default parameters and

if c is None:
  c = int(open(c_source, 'r').read()) # c=8

in the cell after parameters

[willingc]

Recording portion of discussion from NES

Inferred parameters use cases include:

• forms
• discovery of notebooks with particular parameters

[stefise]

Is there any update on this?
Or am I missing an existing way of doing what I want to do - which is, checking out the parameters-cell in my "master"-notebook. The reason to do this is because I want to be able to tell which parameters the "slave"-notebook requires.

Thanks :-)

[MSeal]

There has not been any work on this. Mostly it's been a resource constraint problem for many of us as someone would need to work through the remaining scope ambiguity concerns, get agreement of what would and wouldn't be done, and make a solid PR. Nothing unsolvable, but a bit of work to take on while some of the adjacent projects have needed more attention.