AliasResolutionError with a suspected fix.

[deepandas11]

Describe the bug
I encountered this when using mkdocstrings on a fairly large mono-repo style codebase with mkdocs-monorepo.

The python handler from mkdocstrings would eventually trickle down to griffe.loader.resolve_module_aliases and would fail for a certain file.

Traceback

    data: CollectorItem = handler.collect(identifier, options)
  File "/Users/deepandas/.pyenv/versions/3.8.13/envs/mkdocs_test/lib/python3.8/site-packages/mkdocstrings_handlers/python/handler.py", line 199, in collect
    unresolved, iterations = loader.resolve_aliases(implicit=False, external=False)
  File "/Users/deepandas/.pyenv/versions/3.8.13/envs/mkdocs_test/lib/python3.8/site-packages/griffe/loader.py", line 217, in resolve_aliases
    next_resolved, next_unresolved = self.resolve_module_aliases(module, implicit, external)
  File "/Users/deepandas/.pyenv/versions/3.8.13/envs/mkdocs_test/lib/python3.8/site-packages/griffe/loader.py", line 357, in resolve_module_aliases
    sub_resolved, sub_unresolved = self.resolve_module_aliases(
  File "/Users/deepandas/.pyenv/versions/3.8.13/envs/mkdocs_test/lib/python3.8/site-packages/griffe/loader.py", line 357, in resolve_module_aliases
    sub_resolved, sub_unresolved = self.resolve_module_aliases(
  File "/Users/deepandas/.pyenv/versions/3.8.13/envs/mkdocs_test/lib/python3.8/site-packages/griffe/loader.py", line 357, in resolve_module_aliases
    sub_resolved, sub_unresolved = self.resolve_module_aliases(
  [Previous line repeated 1 more time]
  File "/Users/deepandas/.pyenv/versions/3.8.13/envs/mkdocs_test/lib/python3.8/site-packages/griffe/loader.py", line 335, in resolve_module_aliases
    if not implicit and not member.is_explicitely_exported:
  File "/Users/deepandas/.pyenv/versions/3.8.13/envs/mkdocs_test/lib/python3.8/site-packages/griffe/dataclasses.py", line 827, in __getattr__
    attr = getattr(self.target, name)
  File "/Users/deepandas/.pyenv/versions/3.8.13/envs/mkdocs_test/lib/python3.8/site-packages/griffe/dataclasses.py", line 936, in target
    self.resolve_target()
  File "/Users/deepandas/.pyenv/versions/3.8.13/envs/mkdocs_test/lib/python3.8/site-packages/griffe/dataclasses.py", line 964, in resolve_target
    raise AliasResolutionError(self.target_path) from error

However, I followed a hunch and was able to fix it magically by monkeypatching a fix in expressions:

griffe/src/griffe/expressions.py

Lines 32 to 33 in 2c3b0ce

	def __eq__(self, other: Name | Expression) -> bool: # type: ignore[override]
	return self.full == other.full # noqa: WPS437

I simply added a path to allow str types

def __eq__(self, other: Name | Expression | str) -> bool:  # type: ignore[override]
        if isinstance(other, str):
            return self.full == other
        return self.full == other.full  # noqa: WPS437

To Reproduce
I haven't been able to find a demonstrable repro on a smaller scale, which makes me believe this could also stem from a weird import order issue from the large codebase I am trying to handle.

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):

• griffe version: 0.24.1
• mkdocstrings version: 0.8.0
• Python version: 3.8.13
• OS: MacOS

Additional context
I haven't played around with the library too much and wasn't able to figure out the underlying reason. Looking for more context into this and if possible, to accommodate the simple fix?

[pawamoy]

Hello, thanks a lot for the detailed report, for the time you took to investigate, and for the suggested fix 🚀!

I'm very curious as to how you found that this change would fix the issue. I guess you ran a debugging session?
I also guess your monorepo is not public, and therefore I cannot debug on my end as well, or try to find a MRE 😅?

[deepandas11]

Thanks for the swift response! Appreciate you looking into it.

I'm very curious as to how you found that this change would fix the issue. I guess you ran a debugging session?

Honestly, I didn't spend a lot of time into it, and my hunch originated from the member.is_explicitly_exported check on the traceback. Following that trail led me to this line in dataclasses.py:

griffe/src/griffe/dataclasses.py

Line 409 in 2c3b0ce

return member.name in self.exports

The type hints in the initializer suggests exports is set[str] | list[str | Name], qualifying the __eq__(self, other) on Name for the list[Name] case when other is of type Name, but not for set[str] or list[str]. (Added context from the Python membership test rules, which means __contains__ would implicitly call __eq__)

I also guess your monorepo is not public, and therefore I cannot debug on my end as well, or try to find a MRE 😅?

Unfortunately, yes, it's a private repo, and I did put in some effort into setting up a minimal repro, but that didn't work. I am hoping the traceback, and my line of thought above could assist you in some way?

[pawamoy]

Should be fixed by 37ae0a2, thanks again @deepandas11. I'll try to pack a few more things before the next release.