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

Brian Granger ellisonbg at gmail.com
Fri Apr 12 12:01:16 EDT 2013 

Paddy,

Hi, thanks for your note on this stuff.

We should probably provide a bit of background on current work on the
multidirectory support.  We currently have two people (besides you)
who are working on the implementation of the multidirectory support.
We have one open PR:

https://github.com/ipython/ipython/pull/2982

And Zach Sailer (the author of the IPEP) is working on it as well.  In
our experience, it is difficult, even with GitHub for multiple people
to simultaneously work on the same feature - it takes careful manual
coordination.  Here is our current plan of attack:

(this is also described in a comment on PR #2982)

1. We all pitch in and finish up the design using the IPEP.  We would
love it if you could add some details about the
Notebook/NotebookCollection stuff you describe.  I am not sure if it
will fit in, but it would be nice to have a section in the IPEP that
talks about the possibilities.  If this code is already written, it
might be helpful to point us to a branch where it lives on the IPEP.
2. Zach is then going to implement the server side of things: the
notebook manager stuff and handlers.
3. Then I was hoping that @robyoung could adapt the frontend part of
his PR to that server side implementation.

If @robyoung is doesn't end up helping with the frontend, then either
you or Zach could fill in there.

[I should disclose that Zach is a student of mine and we are paying
him to work on this stuff as part of our Sloan foundation grant]

I hope I don't sounds like I am discouraging you from contributing to
the project.  We actually have a ton of things that people are not
working on.  But the project is big enough now that it takes careful
coordination of the various developers.  In case you haven't seen it,
here is our development roadmap:

https://github.com/ipython/ipython/wiki/Roadmap:-IPython

If there are things on this list you are interested in working on,
please check with us as a lot of these things are already moving
forward.

Cheers,

Brian


On Fri, Apr 12, 2013 at 4:51 AM, paddy mullen <paddy at paddymullen.com> wrote:
> 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
>
>
>
> _______________________________________________
> 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

More information about the IPython-dev mailing list