ImportError: No module named 'breathe'

[qnzhou]

Details

• Read the Docs project URL: https://pymesh.readthedocs.io/en/latest/
• Build URL (if applicable): https://readthedocs.org/projects/pymesh/builds/7860648/
• Read the Docs username (if applicable):

Expected Result

Build without error.

Actual Result

There are several things that is likely wrong in the build:

1. RTD is catting the wrong conf.py. The correct conf file is docs/conf.py, and it is also specified in the RTD settings of the project. However, for some reason, RTD is using the conf.py from a git submodule.
2. RTD fails with the following error:

Traceback (most recent call last):
  File "/home/docs/checkouts/readthedocs.org/user_builds/pymesh/envs/latest/lib/python3.5/site-packages/sphinx/registry.py", line 315, in load_extension
    mod = __import__(extname, None, None, ['setup'])
ImportError: No module named 'breathe'

3. It would be good if I can disable RTD from checking out recursively the git submodules since the documentation of my project does not rely on them, and the submodule tree could be very deep. I have seen other issues mentioning it (Add submodule configuration #4464), but I am not sure it is part of the official release yet.

[stsewd]

Sorry, you are facing #4669. About submodules, I hope to get merged this PR #4493 soon and make it available to users soon.

Probably we can close this issue, and follow up on the others.

[stsewd]

Also, a workaround is creating your .readthedocs.yml file in the root of your project https://docs.readthedocs.io/en/latest/yaml-config.html.

[qnzhou]

Thanks @stsewd , adding .readthedoc.yml does fix the problem, but it still feels like a mystery to me. No where in .readthedoc.yml specifies the location of conf.py, and yet the problem goes away.

[stsewd]

previously the conf.py value was only customizable from the web panel of a project, but we are changing some stuff to make a rtd configuration file v2, which can be used to specify the con.py path, isn't available to users right now. Anyway, all values are relative to this file, so that's the problem. With the last update we discovered this hidden bug (we were reading a configuration file that doesn't belong to the user)