All the cells in my notebook run fine until the very last cell, in which I have:
from nbdev import nbdev_export
Traceback (most recent call last):
File ~/opt/anaconda3/envs/shazbot/lib/python3.8/site-packages/IPython/core/interactiveshell.py:3398 in run_code
exec(code_obj, self.user_global_ns, self.user_ns)
Input In  in <cell line: 3>
File ~/opt/anaconda3/envs/shazbot/lib/python3.8/site-packages/fastcore/script.py:110 in _f
if not mod: return func(*args, **kwargs)
File ~/opt/anaconda3/envs/shazbot/lib/python3.8/site-packages/nbdev/doclinks.py:135 in nbdev_export
File ~/opt/anaconda3/envs/shazbot/lib/python3.8/site-packages/nbdev/doclinks.py:97 in _build_modidx
res['syms'].update(_get_modidx((dest.parent/file).resolve(), code_root, nbs_path=nbs_path))
File ~/opt/anaconda3/envs/shazbot/lib/python3.8/site-packages/nbdev/doclinks.py:75 in _get_modidx
for tree in ast.parse(cell.code).body:
File ~/opt/anaconda3/envs/shazbot/lib/python3.8/ast.py:47 in parse
return compile(source, filename, mode, flags,
SyntaxError: unexpected EOF while parsing
Why is it complaining? The rest of the notebook is fine.
What is “File ”, and how can I trace the output…?
nbdev_export utility gives the same error.
EDIT: tried uninstalling & resintalling
nbdev, to no effect.
Put the import in a separate cell
Thanks for your reply, Hamel! I tried putting it in separate cell but no effect. Same error.
This used to work fine, btw. I’m past version 0.0.13 of my library and that cell has been unchanged all along.
Is it possible that there’s some other file that’s been corrupted – and how would I find out which one? Tried adding “verbose” but didn’t work.
nbdev_export: error: unrecognized arguments: --verbose
SOLVED: In a totally different notebook, there was a typo in the form of an indentation error. With that resolved, everything goes back to working (and I could keep that import in the cell).
Is there a way to have
nbdev_export report which file it’s working on, to make it easier to track down errors?
Currently, I guess not - but there certainly should be!
nbdev_export is a special case where you don’t have to do this.
I’ve made an issue to track this: `nbdev_export` raises an unhelpful error message if a cell's code fails to parse while building modidx · Issue #1169 · fastai/nbdev · GitHub
I think this is an area we could improve at in general, so I’ve also made a higher-level issue: User-friendly error messages · Issue #1168 · fastai/nbdev · GitHub
We don’t often catch exceptions and reraise errors with more specific and friendly messages. My personal preference is for verbose error messages written in a conversational tone with as much useful info for debugging as possible.
I’d like to use this issue to track specific cases of unhelpful error messages, which can each be tracked in their own issue …