added path to the resources metadata, the same as in from_filename(...) in nbconvert.exporters.py

[gabyx]

No description provided.

[gabyx]

analogously to nbconverter.exporterts.py from_filename

[takluyver]

Thanks, I think this makes sense. We should, however, make sure to convert the URL path into an absolute filesystem path using contents_manager.get_os_path(). And this will only be possible with the default file-based contents manager, not with a contents manager that stores notebooks in a database or something.

[takluyver]

We're just preparing to release 5.1, so I've marked this as 5.2 - hopefully we can merge it soon after the release.

[gabyx]

Sounds perfect. I have so far little experience with this, but maybe somebody can correct this. The question arises if nbconvert should also work for other content_managers? or should it primarily be used as a tool when the notebook is stored locally?

…

------ Originalnachricht ------ Von: "Thomas Kluyver" <[email protected]> An: "jupyter/notebook" <[email protected]> Cc: "Gabriel Nützi" <[email protected]>; "Author" <[email protected]> Gesendet: 18.08.2017 13:18:17 Betreff: Re: [jupyter/notebook] added path to the resources metadata, the same as in from_filename(...) in nbconvert.exporters.py (#2753)

Thanks, I think this makes sense. We should, however, make sure to convert the URL path into an absolute filesystem path using contents_manager.get_os_path(). And this will only be possible with the default file-based contents manager, not with a contents manager that stores notebooks in a database or something. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2753 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnhDeNINpQmGrgsbYJ0eU184bC2cbAfks5sZXL5gaJpZM4O1dm8>.

[takluyver]

I think it should work for other content managers, but the path should be 'progressive enhancement' - i.e. nbconvert should work without it where possible, even if it doesn't work as nicely.

[takluyver]

I've pushed a commit to use filesystem paths rather than API paths, and only where the notebook is actually on the filesystem. I don't think there's any way to do this without using a private method of FileContentsManager, unfortunately.

[mpacer]

What was the purpose of this PR? I can't figure out what bug it was supposed to fix or feature it was supposed to implement and it broke PDF exports…

I'm really confused.

[takluyver]

When nbconvert loads the notebook from a named file (i.e. normal use at the command line), the path is available to exporters and templates in the resources dict. They might use this, for instance, to locate associated files referenced by the notebook.

The point of this PR was that the path should also be available in the same way when nbconvert is used through the notebook web interface.

Sorry if this did break the PDF export. I think the fact that it's actually doing a conversion to Latex in a temporary directory and then a PDF build from there means it tends to hit edge cases in dealing with paths.

[takluyver]

Ah, I see from your other comment the issue now. We didn't look carefully enough at nbconvert. path is supposed to be only the directory path containing the notebook, not the full file path. :-( That's neither the first nor the last time we've been bitten by our confusing use of the word 'path'. I only just caught the same mistake in #2949 before merging it.

Now that we can see that, do you want to do a PR to fix it (i.e. separate out 'name')?

[gabyx]

What was path to be supposed for before? It did not exist I think, we added this, no?
maybe we should rename this to something more clear: filePath

[gabyx]

We should really make it clear: notebookFilePath or (notebookDir).

[takluyver]

I think the naming is effectively part of nbconvert's API, so we can't really change that, even though it's confusing. We just need to make what this does match what nbconvert's from_filename does.

[gabyx]

ah ok,

[mpacer]

What I don't understand is why this needs to have access to a file_path anyway? This will fail for contentsmanagers that don't work with filepaths (e.g., pgcontents which works on postgres)…

[mpacer]

↬ @minrk for pointing out that prior to this PR, nbconvert only relied on the contentsmanager to get the content of the notebook

[takluyver]

Right, it's progressive enhancement. We provide the path if there is one, which is the case most of the time, but it's not guaranteed to be there, because the notebook may not have come from a file. This is the same in nbconvert.

[gabyx]

we need the path where the notebook is located because we have exporters (for example embedders in html) which embed images with paths relative to the notebook location.

[mpacer]

Except that nbconvert can't be guaranteed to interpret path that way. I'll just construct the dict ahead of time conditionally instead of on the fly. it'll conflict with #2413 but that'll just have to do.

[mpacer]

Note #2981 addresses this.

[gabyx]

Can somebody enlighten me what the content manager does? is it the abstraction when the notebook runs on a server? I am kind a of a newbie here...

[takluyver]

It deals with loading and saving notebooks and other files. Normally that just means reading and writing files in directories, but you can plug in another content manager to store notebooks in a database, or to store them in files in a different format.

If you know what FUSE is, it's a similar concept to that - a way to use other storage systems kind of like a filesystem.