Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nbconvert 4.2.0 and output in subdirectory #293

Open
pierrepo opened this issue Apr 18, 2016 · 19 comments
Open

Nbconvert 4.2.0 and output in subdirectory #293

pierrepo opened this issue Apr 18, 2016 · 19 comments
Assignees
Milestone

Comments

@pierrepo
Copy link

pierrepo commented Apr 18, 2016

Hi,

nbconvert seems craching when trying to write ouput file in a subdirectory.

In the notebook_test directory I have one simple notebook file test.ipynb. The latter contains a single cell with print("hello world").

When converting to Markdown, nbconvert crashes:

pierre@kiwi> jupyter-nbconvert --to markdown ./notebook_test/test.ipynb --output ./notebook_test/test.md
[NbConvertApp] Converting notebook ./notebook_test/test.ipynb to markdown
[NbConvertApp] Writing 55 bytes to ./notebook_test/./notebook_test/test.md
Traceback (most recent call last):
  File "/home/pierre/.virtualenvs/new_jupyter/bin/jupyter-nbconvert", line 11, in <module>
    sys.exit(main())
  File "/home/pierre/.virtualenvs/new_jupyter/local/lib/python2.7/site-packages/jupyter_core/application.py", line 267, in launch_instance
    return super(JupyterApp, cls).launch_instance(argv=argv, **kwargs)
  File "/home/pierre/.virtualenvs/new_jupyter/local/lib/python2.7/site-packages/traitlets/config/application.py", line 596, in launch_instance
    app.start()
  File "/home/pierre/.virtualenvs/new_jupyter/local/lib/python2.7/site-packages/nbconvert/nbconvertapp.py", line 293, in start
    self.convert_notebooks()
  File "/home/pierre/.virtualenvs/new_jupyter/local/lib/python2.7/site-packages/nbconvert/nbconvertapp.py", line 457, in convert_notebooks
    self.convert_single_notebook(notebook_filename)
  File "/home/pierre/.virtualenvs/new_jupyter/local/lib/python2.7/site-packages/nbconvert/nbconvertapp.py", line 429, in convert_single_notebook
    write_results = self.write_single_notebook(output, resources)
  File "/home/pierre/.virtualenvs/new_jupyter/local/lib/python2.7/site-packages/nbconvert/nbconvertapp.py", line 390, in write_single_notebook
    output, resources, notebook_name=notebook_name)
  File "/home/pierre/.virtualenvs/new_jupyter/local/lib/python2.7/site-packages/nbconvert/writers/files.py", line 127, in write
    with io.open(dest, 'w', encoding='utf-8') as f:
IOError: [Errno 2] No such file or directory: './notebook_test/./notebook_test/test.md'

However, it works perfectly when there is no subdirectory in the output filename:

pierre@kiwi> jupyter-nbconvert --to markdown ./notebook_test/test.ipynb --output test.md
[NbConvertApp] Converting notebook ./notebook_test/test.ipynb to markdown
[NbConvertApp] Writing 55 bytes to ./notebook_test/test.md

The funny thing is that the output file is also written in the same directory of the notebook file.
This does not appear with nbconvert 4.1.0.

I am not sure if this is a bug or a feature.

@pierrepo pierrepo changed the title Bug with nbconvert 4.2.0 and subdirectory Nbconvert 4.2.0 and output in subdirectory Apr 18, 2016
@timstaley
Copy link

timstaley commented Apr 20, 2016

I'm also seeing this with 4.2.0 - nbconvert seems to be effectively changing working directory to the directory of the notebook(?) - so then the relative subdirectory path becomes invalid.

As a quick workaround I'm simply passing nbconvert absolute paths.

timstaley added a commit to timstaley/voeventdb.remote that referenced this issue Apr 20, 2016
@herr-biber
Copy link

I encounter a similar bug. If you give a relative --output path, its relative to the source ipynb

jupyter nbconvert --to html foo/test.ipynb --output test.html
[NbConvertApp] Converting notebook foo/test.ipynb to html
[NbConvertApp] Writing 264082 bytes tofoo/test.html

By bisecting, I found the bug got introduced by commit dd84757.
Prior, a relative --output path was relative to $PWD.

Or is this actually a feature?

@minrk
Copy link
Member

minrk commented May 13, 2016

Arg, no, I think --output should probably be interpreted relative to PWD.

@mpacer
Copy link
Member

mpacer commented Sep 13, 2016

is this supposed to set build_directory when the --output flag is passed in(using the @observe feature of traitlets)? If so, I think the problem is that its not being caught and the resources directory is always getting passed in and appended to the front of the relative path.

This seems to be happening because even when you specify --output, the change['new'] value is ''.

@mpacer
Copy link
Member

mpacer commented Sep 13, 2016

So I think that part of this actually isn't a bug.

The flag for an output directory is supposed to be --output-dir not --output.

And build_directory is changed appropriately if you use --output-dir

So change

jupyter-nbconvert --to markdown ./notebook_test/test.ipynb --output ./notebook_test/test.md

to

jupyter-nbconvert --to markdown ./notebook_test/test.ipynb --output-dir ./notebook_test/test.md

or even better

jupyter-nbconvert --to markdown ./notebook_test/test.ipynb --output-dir ./notebook_test --output test.md

but note that if you try

jupyter-nbconvert --to markdown ./notebook_test/test.ipynb --output-dir ./notebook_test/test2.md --output test.md 

the output will be to test2.md not test.md.

@herr-biber
Copy link

I don't get why there are two output parameters? Why can't we have only a single output parameter (e.g. --output) and rely on shell semantics for relative vs. absolute path handling?

@takluyver
Copy link
Member

You can convert several notebooks with one command to a specified --output-dir. --output only makes sense when converting one.

@mpacer
Copy link
Member

mpacer commented Sep 13, 2016

Ah — so should --output not be behaving in this way? Is it actually a bug?

@takluyver
Copy link
Member

I agree with what Min said above that output should probably be relative to the CWD where you run the command, not the location of the notebook. Is that what you mean?

@mpacer
Copy link
Member

mpacer commented Sep 13, 2016

Not quite, though that was also something I was trying to work out. It looks like there are like three potential issues here.

What I was asking was whether --output is supposed to take paths or only file names (including relative paths).

--output is not triggering build-directory, but it doesn't seem to have been designed to do so. If it had the first reported error on this issue.

--output is not triggering relpath either, even when the path passed in is relative. It is not clear what relpath is used for or where it would be triggered.

I'm not sure where else the code determining whether there was a relative or an absolute path would be… --output doesn't seem to be processed in the FilesWriter.

It's not clear how the cited changes are able to mess with which directory the relative path is being defined from. It seems that the resources path is being used in all of the cases and that relpath is just never defined. But I wasn't certain, I've been trying to piece this together as best I can.

@mpacer
Copy link
Member

mpacer commented Sep 13, 2016

This seems to be related to problems reported in #326.

@mpacer
Copy link
Member

mpacer commented Sep 14, 2016

Ok, so --output has a particular meaning according to its associated help on the output_base traitlet:

overwrite base name use for output files. can only be used when converting one notebook at a time.

So, it seems that it should never be used to specify a path. And so the fact that it had ever been possible was a mistake.

Now I'll try to figure out where the resources path is getting set and see if i can set it relative to the working directory not the notebook directory

@mpacer mpacer modified the milestones: 5.1, 5.0 Sep 14, 2016
@mpacer
Copy link
Member

mpacer commented Sep 14, 2016

Ok, so it seems that there was an explicit decision to make the relpath relative to the directory of the notebook and not the current working directory: e07ef9a#diff-0ede046bf81229fbf9277b1e4e652252

Additionally #341 suggests it should also be relative to the notebook.

However, build-directory is defined relative to the current working directory — not the notebook.

I'm taking this off of 5.0 because we need to come to a consensus around these definitions and expectations since they've sprung up organically and conflictingly.

@takluyver
Copy link
Member

Rats, that does indeed look like we've got ourselves into a confusing corner.

The nbconvert command line interface handles a lot of different things. E.g. if I want to execute a notebook and rewrite the file with output, that's something like jupyter nbconvert --execute --to notebook --inplace .... There's a forest of options, some of which only make sense with other options. Longer term, I think we need to rethink how the CLI works for piecing together the different actions nbconvert can take.

@mpacer
Copy link
Member

mpacer commented May 24, 2017

I feel like we still don't have a consensus around this.

@mpacer
Copy link
Member

mpacer commented May 24, 2017

I can't tell, is this still an issue?

@mpacer mpacer modified the milestones: 5.3, 5.2 May 24, 2017
@takluyver
Copy link
Member

Specifying --output relative/path still produces the confusing behaviour noted before. I think that we should either make it relative to the cwd, or limit it to just the base filename. Of course, this has now been this way long enough that someone is probably relying on it working the way it currently does.

@mpacer mpacer modified the milestones: 5.3, 5.4 Aug 26, 2017
@blink1073 blink1073 modified the milestones: 5.4, 5.5 Aug 29, 2018
@Jwink3101
Copy link

Has there been any update on this? It has been over a year and you still cannot reliably use nbconvert with subdirectories. Some formats need --output-dir while others do not. And some methods can handle a subdir in the input file while others cannot.

It should be consistent. And the most logical behavior is that it respects paths!

@MSeal
Copy link
Contributor

MSeal commented Apr 23, 2019

Moving to 6.0 milestone as the entire build directory process should be considered in how it operates and changing it in 5.x would cause too much disruption.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants