-
-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to build documentation for the ibis project #72
Comments
Thanks for the very detailed report! Griffe does not support the Now the issue here is more that the existing alias with name |
OK, your wildcard imports are a bit too wild for Griffe. I was able to fix the issue with line numbers, and then faced multiple cyclic aliases errors. Your code works because Python, but doing inference is hard. In -from ibis.backends.dask.execution import constants
+from ibis.backends.pandas.execution import constants Importing from dask works, because there constants are wildcard imported from another dask submodule which imports it from the pandas backends. Then more cyclic alias errors that I was able to suppress in different parts of the code. Serialization still crashes with infinite recursion 😕 But you shouldn't need serialization for building your docs. Now I have to admit that Griffe's data model is not perfect. It still considers submodules like members, when clearly it should not. In Python it seems that even if you define a member in a module using the same name as one of the module's submodules, you can still import from that submodule (import machinery and attribute access are different). I'll have to refactor it. It promises to be a challenging task 😅 I'll post an update here when I feel like I can push a fix. |
…d attribute Issue #72: #72 Issue #79: #79 Issue mkdocstrings/mkdocstrings#438: mkdocstrings/mkdocstrings#438
So the |
Hello @cpcloud, I've released quite a number of bugfixes, could you give Griffe another try? I'm having trouble setting up a dev environment for your ibis project, I've followed the docs, but am still missing dependencies.when running |
Hey @pawamoy, really warms my heart to get this message in my inbox. I'll give it go and report back! |
Ok, wow. This is really close. Good newsLet's start with the good news: after a few changes I am able to build and render the API documentation using the latest version of Loving the new bells and whistles, especially the interlinking of types in the Not as good news, but hopefully fixable without a huge amount of work.
Traceback
Traceback
Traceback
After commented out the code related to 1, 2 and 3 and fixed the broken docstring I was able to render things successfully! |
That's great! Thanks a lot for trying the new version and reporting back! For issues 2 and 3, could you re-run with MkDocs' |
I dropped into pdb using this:
And uncovered this:
Looks like some kind of custom Hopefully that's useful! |
Thanks! Yes I was able to find this as well in a debugging session 🙂 (had the clever 🥸 idea to disable all plugins except mkdocstrings, this way I don't need to install/setup anything special to test). |
About the other two: of course, inherited members are not yet supported 😅 |
Also, the bug was triggered thanks to the missing type here: https://github.com/ibis-project/ibis/blob/master/ibis/config.py#L110 (interactive, in Attributes section of Repr). |
Is there any way to get rid of the
? We like to build with |
I'll change the level to DEBUG 👍 |
Griffe 0.25.3 and mkdocstrings-python 0.8.3 released 🚀 |
Thank you for all that you do! |
Describe the bug
A clear and concise description of what the bug is.
When running
mkdocs build
onmaster
ofibis
I get the following traceback:To Reproduce
mkdocs build
Expected behavior
I would expect the docs to build without error :)
System (please complete the following information):
griffe
version:Additional context
I dug around a bit with
ipython --pdb -m mkdocs build
.It looks like
griffe
maybe isn't correctly tracking__all__
when it's computed instead of a constant hand-curatedlist
which makes star imports (which we use sparingly in ibis) include aliases from other modules.Here's the final stack frame in the traceback of that debugging session:
Here
com
is technically a member ofibis.expr.types.analytic
but it's not part of__all__
(computed using@public
), so ideally it isn't picked up.The text was updated successfully, but these errors were encountered: