Load configuration when setting up handlers

[ryanlovett]

One can configure the nbconvert application via command-line or config file, e.g.
$ jupyter nbconvert --PDFExporter.latex_command='["xelatex", "{filename}"]' --to pdf has_unicode.ipynb

or

$ cat ~/.jupyter/jupyter_nbconvert_config.py                                               
c.PDFExporter.latex_command = [u"xelatex", u"{filename}"]
$ jupyter nbconvert --to pdf has_unicode.ipynb

however this does not affect the notebook handler (File > Download as > PDF via LaTeX (.pdf)).
From @minrk at https://gitter.im/jupyter/notebook?at=5718d4f2b129b59c56da3552:

the nbconvert config file isn't loaded because config loading is done at the "application" level, in this case "notebook".

We should load nbconvert config when setting up the nbconvert handlers, though.

[mpacer]

I know that the notebooks server does not load jupyter_nbconvert_config.py if it is local, and I believe it will also defer to its use if it's lower in the config hierarchy. I'm going to close this, but if this is still an issue @ryanlovett I'm happy to reopen.

[ryanlovett]

Hi @mpacer, this is an issue for us again. In #947 we need to return an error if latex does so that the user doesn't believe the generated PDF is valid when it isn't. However this has exposed that bibtex's return code is effectively ignored. With the current behavior this never mattered, but it would if we checked the output. If we try to bypass bibtex by setting c.PDFExporter.bib_command = ['true'] in jupyter_nbconvert_config.py, it will work when nbconvert is run from the command-line but not when run from Jupyter File > Download as.

I think the real issue affecting us is the handling of the return codes, but enabling Jupyter to know about the nbconvert config would give us a workaround until it is addressed.