IPEP 16: Notebook multi directory dashboard and URL mapping

[Zsailer]

See the details at IPEP 16

[ellisonbg]

Let's not put the entire IPEP in the issue though. Can you remove it and just post a link to the IPEP wiki page?

[ellisonbg]

Also can you post a link on the IPEP page that points to this issue?

[ellisonbg]

Some initial work on this has been done in PRs #3168 and #2982. Those PRs have been closed until we finish the design, but can be used as reference for the design.

[minrk]

My main problem with the design proposed here is that it does not actually solve the issue of multiple notebook servers. Since @ellisonbg clarified that the notebook server will remain confined to some 'server' directory, the only way a user can reasonably run their whole universe from a single notebook server (the goal) is to always run it in $HOME.

I still think we want to preserve the notion of 'projects', where a project is a directory that can contain notebooks, data, etc. (hierarchically). What I think this proposal encapsulates is still a single project. What I would like to add to this is the notion of project, and the notebook server's awareness of multiple projects, analogous to the GitHub github.com/organization landing page. The remaining question there is how does one tell the notebook server about project directories? config files? a special /create-project handler that takes a path, and adds it to the project list?

[paddymul]

Can we set it up so that kernels are always started in the same directory as the ipynb file? Why does each notebook instance need to share a global notebook directory?

[minrk]

@paddymul there are two logical choices for the kernel cwd - one is the ipynb location, and the other is the project directory (so you could have a small amount of notebook organization, without having to keep specifying cd ..). If, as proposed here so far, we are abandoning the notion of the project, the cwd will have to be the ipynb location.

[Zsailer]

I added another section to the IPEP under "Things to consider." I mention the notion of "projects" and even chart out a possible URL scheme for the future. After Min and I talked, I like the idea of making projects a second stage to this proposal. We'll work on implementing a hierarchical dashboard in a single project, then move to a multi-project design on a single server for the notebook.

[takluyver]

I would leave the 'project' notion for now, and just have it able to open files that are in any location, like a text editor.

What we do with the dashboard, I'm not sure. Arguably the logical continuation of our current dashboard is a web-based file manager, but we've said we don't want to go down that route.

[Zsailer]

I agree. Projects are something to consider in the future. We should just keep this notion in our minds, however, and create a multi-directory set of web-services that behave in the backend like a 'single' project. That way, it will be easier to extend this to a multiple project notebook/dashboard when we want to introduce this notion.

[Zsailer]

Also, @ellisonbg and I have changed the web-services and URL mapping for this proposal quite a bit. I'll update this IPEP soon.

[minrk]

Projects are something we already have - a directory of notebooks (and data), the notebook server currently supports just one project at a time. The only piece missing from a full single-project server is exposure of sub-directories. The logical next step after that is a mechanism / UI to add new projects from the filesystem, and UI for listing projects. That would cover opening any notebook anywhere on the filesystem, and we never need to introduce the notion of notebooks independent of projects.