mkdocstrings: mkdocstrings might not work with editable installs in the new setuptools
This is a preliminary bug report based on what I know so far, so I apologize if it is not complete.
setuptools just released version 64.0.0
https://setuptools.pypa.io/en/latest/userguide/development_mode.html
It features a new way of handling editable installations
https://peps.python.org/pep-0660/
It seems that the new mechanism doesn’t work with mkdocstrings. If I do an editable install, mkdocstrings reports
ERROR - mkdocstrings: PACKAGENAME.MODULENAME could not be found
ERROR - Error reading page 'MODULENAME.md':
ERROR - Could not collect 'PACKAGENAME.MODULENAME'
If I install the same package normally (not editable), mkdocstrings works again.
We can work around the problem, but I wanted to post the issue now as it might affect others.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 1
- Comments: 20 (10 by maintainers)
Commits related to this issue
- feat: Support `setuptools` editable modules Issue mkdocstrings/mkdocstrings#463: https://github.com/mkdocstrings/mkdocstrings/issues/463 — committed to mkdocstrings/griffe by pawamoy 2 years ago
This should be supported in the next release of Griffe.
Finally, note that you don’t have to rely on Griffe’s ability to understand editable modules: you can tell it to search directly in
src(now that you have a proper layout) with this:You’re welcome!
Also, it was working before because Griffe would not find
gemdatand fallback on inspection, trying (and succeeding) to import it, and you were only injecting docs with::: gemdat. Within the docs branch, you’re now also injecting docs forgemdat.plots, and it happens thatinspect.getmembersreturns submodules of the gemdat packages, except theplotssubmodule, probably because it’s a folder and needs to be imported to appear in its parent.Yeah, I switched to the more conventional directory structure and all works as expected now. Thanks for your help debugging this!
Oh right, I didn’t notice modules were stored directly under
srcand notsrc/gemdat😅 I would have immediately pointed at that otherwise 🙂Ah I see it only happens in the docs branch:
git checkout docs --Workaround: using strict editable installs solves this. However, the implementation details are not finalized yet, and may change in the future.
Instead of:
… we could use:
That’s perfect, thanks. I see we could regex-find the
MAPPINGvalue, to start at least. We’ll need to try editable installs for namespace packages as well (great to learn they support them), but that can be done later. By the way all this detection happens in Griffe, if someone wants to try and send a PR 😃 Otherwise I’ll eventually get to it.