All the cells in my notebook run fine until the very last cell, in which I have:
#| hide
from nbdev import nbdev_export
nbdev_export()
This produces
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 [45] in <cell line: 3>
nbdev_export()
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
_build_modidx()
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,
File <unknown>:115
^
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…?
The command-line nbdev_export utility gives the same error.
EDIT: tried uninstalling & resintalling nbdev, to no effect.
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.
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?
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 …