Min RK

Historically, we've described this kind of information as out-of-scope for the notebook itself, in part because it's already solved well by an `environment.yml` (or requirements.txt, Dockerfile, etc.) in the top-level...

I don't love including the environment _specification_ in the notebook document because it works very poorly once you have more than one document. But including a 'reference' to the environment...

This would be a single output area on the notebook, for example: ```python nb.global_outputs = [ ... ] ``` otherwise identical to the `.outputs` list of a code cell?

I would say that `check_cells` and `mark_cells` probably should not be in nbformat at all (they were defined here before the web application and document format were moved to separate...

I think this makes sense as a simplification of things. Right now, I think we have this in the notebook application: - if kernelspec name matches, use that one (seems...

@janschulz I think we'll make sure that's well supported. It's how I work as well. I think we have to keep some version of remembering which local kernelspec was used,...

Ah, interesting. I was thinking that much of the problem was things like nbconvert disagreeing with the live notebook, not codifying that the two *should* be very different. nbval seems...

I certainly agree that this proposal's addition of the kernel-selection strategy as a clear axis of configuration should make it easier to make things match or not, and defaults for...

I believe resource-limiting preferences in the docker config itself is the way to do this. Right, @rgbkrk?

> Modifications to jupyter-singleuser will also be required to support pooling. More precisely, modifications to the container entrypoint would be needed, not necessarily `jupyterhub-singleuser`. This could be modifications to `jupyterhub-singleuser`,...