Skip to content
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

Bases links aren't correct #5

Closed
samuelcolvin opened this issue Feb 23, 2022 · 11 comments
Closed

Bases links aren't correct #5

samuelcolvin opened this issue Feb 23, 2022 · 11 comments

Comments

@samuelcolvin
Copy link

samuelcolvin commented Feb 23, 2022

Describe the bug

Thanks so much for mkdocstrings, I remembered this project from a conversation we had years ago. I'm now using it on a library I'm just writing docs for dirty-equals.

I've managed to set everything up the way I want it, except the "Bases" links are not working quite right.

This is because I have types declared in dirty_equals._numeric but recommended for import from dirty_equals. This is meaning that while heading ids are correct (e.g. dirty_equals.IsNumeric), bases is generating a link of #dirty_equals._numeric.IsNumeric.

To Reproduce
Steps to reproduce the behavior:

  1. PR showing the problem is use mkdocstrings samuelcolvin/dirty-equals#11
  2. docs preview is https://smokeshow.helpmanual.io/07072c0r385x5x6x3u2d/, try the first "Bases" link.

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

System (please complete the following information):

  • Python version: 3.10
  • OS: Linux/macos

docs requirements:

black==21.12b0
mkdocs==1.2.3
mkdocs-material==8.2.1
mkdocstrings[python]==0.18

Any suggestions on a workaround or when a fix might be available would be wonderful.

@samuelcolvin samuelcolvin changed the title bases links aren't correct Bases links aren't correct Feb 23, 2022
@samuelcolvin
Copy link
Author

I'm going to merge the above PR as it's better than what I have at the moment, but the problem is still there.

@pawamoy
Copy link
Member

pawamoy commented Feb 24, 2022

Hello @samuelcolvin!

Thanks so much for mkdocstrings, I remembered this project from a pydantic/pydantic#1339 (comment) years ago. I'm now using it on a library I'm just writing docs for dirty-equals.

Hehehe glad you like mkdocstrings 😊


I think I know why bases use the canonical path rather than the public path (and I actually encountered this issue myself).
It's because when resolving aliases and expanding wildcards, I'm reaching to the final target in a chained aliases list.
Let me see if I can fix this, it shouldn't be too hard.

@pawamoy
Copy link
Member

pawamoy commented Feb 24, 2022

OK it's an issue in mkdocstrings in fact, not Griffe, nor the Python handler 😄

@samuelcolvin
Copy link
Author

Thanks so much for looking into this, please let me know via this issue when it's solved and i'll uprev dependencies.

@pawamoy
Copy link
Member

pawamoy commented Mar 1, 2022

Could you try again with mkdocstrings 0.18.1?

@samuelcolvin
Copy link
Author

samuelcolvin commented Mar 1, 2022

Thanks so much.

See samuelcolvin/dirty-equals#21.

Doesn't seem to work I'm afraid, see https://smokeshow.helpmanual.io/462a72276u0d3s2w4p1c/types/numeric/#dirty_equals.IsInt as an example.

@pawamoy
Copy link
Member

pawamoy commented Mar 1, 2022

OK, I think it also needs mkdocstrings/autorefs#15 to work.
EDIT: yup, confirmed locally. Waiting for oprypin's review on that PR 🙂
Thank you very much for testing this quickly!

@pawamoy
Copy link
Member

pawamoy commented Mar 7, 2022

Just released mkdocs-autorefs 0.4.0, should be fixed now 🙂

@samuelcolvin
Copy link
Author

I seen to still be getting errors. I'm AFK but will look later.

Or you can create a fresh PR to check.

@pawamoy
Copy link
Member

pawamoy commented Mar 7, 2022

OK, this time it should be good 😫 🤞

@samuelcolvin
Copy link
Author

great, thanks working. Thank you so much.

@pawamoy pawamoy closed this as completed Mar 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants