nbconvert: Final output file should be in same directory as input file

[dpsanders]

nbconvert acts, in the end, as a filter to process one format (.ipynb) to another, e.g. .html or .pdf

As such, the output should, by default, be placed in the same directory as the original input file, whatever machinations have to go on in between. I am sure most users would expect this.

For this reason, the current nbconvert system is fundamentally flawed, in my opinion, since one has to manually change directories, and the .html, .tex and .pdf outputs end up inside the nbconvert_build directory, mixed up with the miscellaneous "garbage" that gets produced in the conversion process.

As an end user, I should not clear about what goes on in this process, and certainly should not be forced to contemplate this garbage. The .aux, .log etc. nonsense from LaTeX is bad enough.

The solution is clear: the .tex, .pdf and .html files should end up in the original directory. In the case of LaTeX processing, this is easily accomplished using the \graphicspath{{nbconvert_build}} specification.

There should, finally, be an option to remove the nbconvert_build directory. Or rather, the flag should be to leave it there once finished, and the default should be to delete it.
Probably the conversion process should also not clobber a pre-existing nbconvert_build directory, but rather generate nbconvert_build1 etc.

It would also be necessary, in this point of view to have options to leave just the final PDF in either the sphinx_howto method or the latex method. In fact, this should rather be the default, so that nbconvert becomes the converter that everybody really wants.

From my point of view, this should be in 1.0 to avoid a lot of problems with people not understanding how to get out their PDF at the end...

[ellisonbg]

I think we will probably have to discuss this at the dev meeting next week
to finalize the design of the file system writer.

On Fri, Jul 19, 2013 at 7:38 PM, David Sanders notifications@github.comwrote:

nbconvert acts, in the end, as a filter to process one format (.ipynb) to
another, e.g. .html or .pdf`

As such, the output should, by default, be placed in the same directory
as the original input file, whatever machinations have to go on in between.
I am sure most users would expect this.

For this reason, the current nbconvert system is fundamentally flawed, in
my opinion, since one has to manually change directories, and the .html,
.tex and .pdf outputs end up inside the nbconvert_build directory, mixed
up with the miscellaneous "garbage" that gets produced in the conversion
process.

As an end user, I should not clear about what goes on in this process, and
certainly should not be forced to contemplate this garbage. The .aux, .logetc. nonsense from LaTeX is bad enough.

The solution is clear: the .tex, .pdf and .html files should end up in
the original directory. In the case of LaTeX processing, this is easily
accomplished using the \graphicspath{{nbconvert_build}} specification.

There should, finally, be an option to remove the nbconvert_builddirectory. Or rather, the flag should be to
leave it there once finished, and the default should be to delete it.
Probably the conversion process should also not clobber a pre-existing
nbconvert_build directory, but rather generate nbconvert_build1 etc.

It would also be necessary, in this point of view to have options to leave
just the final PDF in either the sphinx_howto method or the latex method.
In fact, this should rather be the default, so that nbconvert becomes
the converter that everybody really wants.

From my point of view, this should be in 1.0 to avoid a lot of problems
with people not understanding how to get out their PDF at the end...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3701
.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

[dpsanders]

Will it be possible to participate remotely in some way? Via hipchat / video?

[ellisonbg]

We can arrange for you to participate in the relevant parts - especially
the nbconvert stuff.

On Fri, Jul 19, 2013 at 8:33 PM, David Sanders notifications@github.comwrote:

Will it be possible to participate remotely in some way? Via hipchat /
video?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3701#issuecomment-21285007
.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

[dpsanders]

OK, great. Or you can just invite me to SF ;)

[ellisonbg]

Where are you located?

On Fri, Jul 19, 2013 at 8:36 PM, David Sanders notifications@github.comwrote:

OK, great. Or you can just invite me to SF ;)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3701#issuecomment-21285050
.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

[dpsanders]

Mexico City...

[jakobgager]

I don't totally agree with you, placing the .tex file in the same folder as the original .ipynb (source folder).
Personally, I like the separate folder approach as I can quickly run pdflatex without cluttering my source folder with all the latex garbage files you already mentioned. Moreover, as more or less all files in it are working files they can be deleted without any problems.
In the long run, if the pdflatex call is invoked by nbconvert, the final pdf could be automatically placed in the source folder - this would be OK!

[dpsanders]

Right, I agree with you.
I think I can summarize as follows:

What I want nbconvert to do is exactly the following:

• read the notebook.ipynb file from a given folder
• write the notebook.pdf file to that same folder

I do not want to know what complicated mess is going on to get from (a) to (b) -- this should be completely invisible to me, unless I set a flag which makes it visible (for example, because I want to keep the individual PDFs of each figure generated, which I would definitely want inside a subdirectory called figures [not nbconvert_build!])

[minrk]

closed by #3734