[IPython-dev] New IPEP for a multi-directory notebook in IPython

paddy mullen paddy at paddymullen.com
Fri Apr 12 07:51:25 EDT 2013


I have an implementation that I have been working on.  I will get a pull request together.   My code in filenbmanager became much cleaner and more understandable once I made a Notebook object.  I also made a NotebookCollection object that managed all the possible lookups to find a notebook.  

For URLs I have added two new routes
/notebook_direct which leads to urls like /notebook_direct//Users/paddy/foo.ipynb
and
/notebook_relative which has paths that are relative to the base notebook directory.

What issues were there previously with path based notebooks?  
One question that I have run into is, what directory do New Notebooks end up in?




On Apr 12, 2013, at 5:26 AM, Matthias Bussonnier <bussonniermatthias at gmail.com> wrote:

> How does this integrate with db back end ? 
> I know url that reflect notebook location seem great, and useful in most cases, because server run local where server is. But it is causing confusion, especially with the /files handler. 
> 
> Le vendredi 12 avril 2013, MinRK a écrit :
> 
> 
> 
> On Thu, Apr 11, 2013 at 9:40 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> On Thu, Apr 11, 2013 at 9:14 PM, MinRK <benjaminrk at gmail.com> wrote:
> > We do need to figure this one out.  There are still some questions to work
> > out:
> >
> > What does `foo/bar` resolve to? Is it relative to the initial notebook
> > server directory, or is it absolute?
> 
> I was thinking it is relative to the initial notebook server dir, so
> users can limit the notebook servers access to the file system.  We
> don't want "/" to actually mean "/".
> 
> But that's problematic as well - if you isolate the notebook server, but allow navigation within that directory, you aren't really solving the issue of needing multiple notebook servers for multiple notebook directories unless people always start their notebooks in $HOME.
> 
> I still think our original 'project' notion was a good one, and I don't know why we seem to be abandoning it.
>  
> 
> > We already have redirects for notebook name -> notebook id URLs, perhaps
> > rather than having 'true' paths in the URLs, we have project-ids, just like
> > we have notebook-ids, and a redirect handler for loading a project,
> 
> Yes, we could do the redirects, but I have a feeling that the redirect
> stuff is simply going to take us closer and closer to actually getting
> rid of the notebook_id/project_id approach.
> 
> The difference is that when we are using redirects, the user-friendly URLs are transient, so we don't have issues of preserving state across variations (the rename issue).
>  
> 
> > i.e:
> >
> >     /project/path/to/notebook-dir redirects to /project-id/
> >
> > and /project/path/to/notebook-dir/notebook.ipynb redirects to
> > /project-id/notebook-id
> 
> > The reason we have notebook-id URLs is that handling the url rewrites /
> > redirects on notebook renames might be tricky.  It could be that redirects
> > are a sensible  compromise.
> 
> I know how to do the dynamic URL rewriting.  This is what GitHub uses
> now that it allows you to rename files in edit mode.
> 
> The big problem is if a rename happens when someone else has the same
> notebook open.  Then, the other person doesn't know the rename
> happened and when they save, it will write the notebook with the old
> name.  But maybe this is OK - our live notebook sharing is actually
> broken already - this example just shows that we need to fix it for
> real.  But it is risky as a single user can run into this if they open
> the notebook page in two tabs or browsers.
> 
> But I also have some vague recollections that there were some problems
> with Untitled notebooks as well.
> 
> The issue with this was the renames - 100% of notebooks have the initial name Untitled0, so every notebook you create in a given session started with the same name.  In my semi-persistent notebook-id PR, I address this as well.
>  
> 
> Cheers,
> 
> Brian
> 
> >
> > On Thu, Apr 11, 2013 at 6:14 PM, Paul Ivanov <pi at berkeley.edu> wrote:
> >>
> >> Zachary Sailer, on 2013-04-11 17:34,  wrote:
> >> > Hi everyone,
> >> >
> >> > Take a look at the new IPEP added to the IPython wiki page,
> >> > IPEP 16: Notebook multi directory dashboard and URL mapping.
> >> >
> >> >
> >> > https://github.com/ipython/ipython/wiki/IPEP-16%3A-Notebook-multi-directory-dashboard-and-URL-mapping
> >>
> >> Looks pretty good, Zach - I adjusted some wording to emphasize
> >> just how bad the problem is (you have to restart the server, or
> >> start a new one, not just a new dashboard).
> >>
> >> I'm a bit confused by the wording of 'notebooks' and 'app' -
> >> where you says something about the possibility of having
> >> a folder named 'notebooks' -- what if the user has a folder named
> >> 'app'?
> >>
> >> best,
> >> --
> >> Paul Ivanov
> >> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> >
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> 
> 
> 
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
> 
> _______________________________________________
> 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/20130412/ab6b9056/attachment.html>


More information about the IPython-dev mailing list