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

griffe 0.25.1 errors with CyclicRedundancy on uuid #123

Closed
digitaldogsbody opened this issue Dec 21, 2022 · 11 comments
Closed

griffe 0.25.1 errors with CyclicRedundancy on uuid #123

digitaldogsbody opened this issue Dec 21, 2022 · 11 comments

Comments

@digitaldogsbody
Copy link

Describe the bug
Since moving from 0.25.0 to 0.25.1, previously building documentation started failing, with a CyclicAliasError pointing at uuid.

We are using mkdocs >=1.4.0, <2.0.0 and mkdocstrings-python >=0.7.0, <1.0.0, with the python show_submodules option enabled in mkdocs.yml and a single "code" markdown file that points to the root of the library.

The application code itself only contains a single include of the uuid library in one file, so I am not certain how there could be a cyclic issue.

Forcefully pinning griffe==0.25.0 in the requirements makes the build succeed again, with no change to the application code.

To Reproduce
Steps to reproduce the behavior:

  1. Go to https://github.com/iiif-prezi/iiif-prezi3 and clone the repo
  2. Run command pip install griffe==0.25.1
  3. Run command mkdocs build --strict
  4. See error

Expected behavior
The documentation should build successfully.

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

System (please complete the following information):

  • griffe version: [e.g. 0.2.1] 0.25.1
  • Python version: [e.g. 3.8] 3.8.10 (also observed with 3.10 on a github runner)
  • OS: [Windows/Linux] Linux Mint 20.3 (local) and Ubuntu 22.04.1 (github runner)

Additional context
Add any other context about the problem here.

@pawamoy
Copy link
Member

pawamoy commented Dec 21, 2022

Errr, fixing something and breaking something else 😅
Thanks for the report, I'll investigate and fix ASAP.

@digitaldogsbody
Copy link
Author

Thankyou! Please let me know if there's anything I can do to assist with the process (testing etc).

I started looking into it a bit more, and in terms of the dependency path, I realised there are actually two import * statements in the chain:

  1. The main library imports everything from the helpers submodule: https://github.com/iiif-prezi/iiif-prezi3/blob/main/iiif_prezi3/__init__.py#L1
  2. The helpers module usually imports classes explicitly from its files: https://github.com/iiif-prezi/iiif-prezi3/blob/main/iiif_prezi3/helpers/__init__.py, but in this case (L7), it is using from .auto_fields import * (auto_fields.py is where the import uuid statement is located.

This could potentially be the cause of the issue? If it were a single import * causing the issue, I'd expect to see an earlier failure on one of the other helper files.

I will try updating that init in helpers to explicitly import the classes from auto_fields and report back whether or not that makes a difference.

@digitaldogsbody
Copy link
Author

It did indeed remove that error - but another one appeared in its place for an import of typing.Union. However there was also a secondary error that might be useful for debugging:

ERROR    -  Error building page 'code.md': Cyclic aliases detected:
              typing.Union
Traceback (most recent call last):
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/mkdocs_autorefs/plugin.py", line 78, in _get_item_url
    return self._url_map[identifier]
KeyError: 'iiif_prezi3.skeleton.Union'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/mike/projects/iiif-prezi3/.venv/bin/mkdocs", line 8, in <module>
    sys.exit(cli())
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/mkdocs/__main__.py", line 250, in build_command
    build.build(cfg, dirty=not clean)
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/mkdocs/commands/build.py", line 329, in build
    _build_page(file.page, config, doc_files, nav, env, dirty)
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/mkdocs/commands/build.py", line 234, in _build_page
    output = config.plugins.run_event('post_page', output, page=page, config=config)
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/mkdocs/plugins.py", line 520, in run_event
    result = method(item, **kwargs)
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/mkdocs_autorefs/plugin.py", line 205, in on_post_page
    fixed_output, unmapped = fix_refs(output, url_mapper)
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/mkdocs_autorefs/references.py", line 191, in fix_refs
    html = AUTO_REF_RE.sub(fix_ref(url_mapper, unmapped), html)
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/mkdocs_autorefs/references.py", line 157, in inner
    url = url_mapper(unescape(identifier))
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/mkdocs_autorefs/plugin.py", line 107, in get_item_url
    url = self._get_item_url(identifier, fallback)
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/mkdocs_autorefs/plugin.py", line 83, in _get_item_url
    new_identifiers = fallback(identifier)
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/mkdocstrings/handlers/base.py", line 508, in get_anchors
    anchors = handler.get_anchors(handler.collect(identifier, fallback_config))
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/mkdocstrings_handlers/python/handler.py", line 228, in collect
    if doc_object.docstring is not None:
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/griffe/dataclasses.py", line 914, in docstring
    return self.target.docstring
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/griffe/dataclasses.py", line 1082, in target
    self.resolve_target()
  File "/home/mike/projects/iiif-prezi3/.venv/lib/python3.8/site-packages/griffe/dataclasses.py", line 1106, in resolve_target
    raise CyclicAliasError([self.target_path])
griffe.exceptions.CyclicAliasError: Cyclic aliases detected:
  typing.Union

iiif_prezi3.skeleton does import Union from the standard typing library (as well as a bunch of others), and it is still behind an from .skeleton import * in the root of the library, so I guess if you call from iiif_prezi3 import * then you are still getting a "double import * chain" situation.

@digitaldogsbody
Copy link
Author

I've pushed the version with the modified import for auto_fields to a branch here: https://github.com/iiif-prezi/iiif-prezi3/tree/griffe_debugging

@pawamoy
Copy link
Member

pawamoy commented Dec 21, 2022

Thank you for the investigation! That's really helpful.

90% of Griffe bugs come from wildcard imports indeed. They're a PITA to handle :/ I always recommend avoiding them, but I understand how convenient they might be.
I should probably try again to find some technical spec on how they are handled by Python itself, like an algorithm or something.

The way we handle indirections would probably benefit from a proper design as well. I've implemented it on top on the existing, simple data structures.

Anyway, enough ramblings. Time to write proper tests for wildcard imports.

@digitaldogsbody
Copy link
Author

Unfortunately due to the nature of our library, it's difficult to avoid, because we need to expose classes from the submodules as if they were part of the base module, and we have a model file that is generated by datamodel-code-generator, so it can change frequently and we always need to expose everything inside it.

We have managed to limit the use of from X import * to two statements in the init of the main library, but I will see about implementing some tooling to replace these with an explicit list that is autogenerated.

Keep me posted if there's anything else I can do :)

@pawamoy
Copy link
Member

pawamoy commented Dec 23, 2022

Hi @digitaldogsbody, it seems I cannot replicate the issue anymore in your repository 🤔
But I don't see any major change in the codebase in the last commit, so I wonder if you can still replicate? If yes, how?

@digitaldogsbody
Copy link
Author

I can replicate both the original issue (with uuid) against the code in main and the second one (with typing.Union) against the code in griffe_debugging by running mkdocs build in the root of the repo.

griffe is 0.25.1 and pip freeze | grep mkdocs reports this:

mkdocs==1.4.2
mkdocs-autorefs==0.4.1
mkdocs-material==8.5.11
mkdocs-material-extensions==1.1.1
mkdocstrings==0.19.0
mkdocstrings-python==0.8.2

Running pip install griffe==0.25.0 is enough to get mkdocs to start building again without any other changes.

@pawamoy
Copy link
Member

pawamoy commented Dec 23, 2022

Ah, my bad, I forgot I had patched griffe in the venv itself yesterday. Thank you for helping me remember that :) Hopefully I won't bother you again until it's resolved :)

@pawamoy
Copy link
Member

pawamoy commented Dec 23, 2022

Should be fixed in 0.25.2 (both cases, in your main and griffe_debugging branches), let me know if you still encounter a similar issue and I'll reopen 🙂

@pawamoy pawamoy closed this as completed Dec 23, 2022
@digitaldogsbody
Copy link
Author

Happy to confirm the fix working here. Thanks so much for your speedy work on this, it's really appreciated.

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