[IPython-dev] Notebook filename badness

[Dave Hirschfeld]

Thomas Kluyver <takowl <at> gmail.com> writes:

> 
> On 27 June 2012 02:10, Brian Granger <ellisonbg <at> gmail.com> wrote:
> > What I am proposing would *improve* local use dramatically:
> >
> > * Persistent URLs that you can bookmark and reload across sessions.
> > * No more worrying about accidentally renaming/uploading over an
> > existing notebook.
> > * A natural place for autosave files.
> 
> But as a local application, I expect it to work with regular files in
> normal locations on my filesystem. Our intention was 'directory as
> project' - you can have your notebook files alongside data files and
> Python modules. Eventually, I'd like to be able to double click the
> ipynb files in my file manager to load them, rather than having to
> load up our 'notebook list' as a file manager.
>
> This approach has lots of advantages that I don't think we want to
> throw away. You can easily put a project in version control, or keep
> it in Dropbox or similar services. You can quickly grab the file and
> attach it to an email. You can easily back up the project folder.
> Notebooks tucked away in a separate folder and named by meaningless
> UUIDs would be much less convenient in many ways.
>
> Perhaps I can suggest an alternative approach: in 'local application'
> mode, we don't try to offer a notebook manager. It's never going to be
> as good as native file managers, and we're not really interested in
> reimplementing that functionality. If you want to copy notebooks,
> delete them, etc., you do it in your file manager (or terminal, if you
> prefer). It would still need to detect conflicts when you 'save as'
> from the notebook interface, but I'm sure we can make that work.

+1

Just a couple of comments from a user, take them as you will:

In our team we're quite often using notebooks to document our work on various
topics. Collaboration quite often takes the form of emailing the .ipynb
file to other team members so having it as a normal, sensibly named file is 
important so that we know which of dozens of notebooks is the correct one to 
send.

I think the guid from a full path name is sensible for this local working 
scenario - if you're silly enough to work on the same notebook in two 
different tabs after renaming the file in one then the pain of merging the 
divergent .ipynb files will be a salutory lesson for in future!

In this use case I'm also very interested in being able to open a .ipynb file 
locally without having to go through the file manager frontend. As Thomas 
mentioned, when it's local it's easy to manage the files in windows explorer (or 
equivalent) and when you've been sent a file it's (very marginally) easier to be 
able to open it directly rather than hunt for it in a list.


Regards,
Dave