8000 feature: Add `try_relative_path` option (for Griffes) · Issue #145 · mkdocstrings/python · GitHub
[go: up one dir, main page]

Skip to content
feature: Add try_relative_path option (for Griffes) #145
Closed
@pedro-psb

Description

@pedro-psb

Is your feature request related to a problem? Please describe.

I'm working on a project that aggregates docs from multiple repos by copying their content to a tempdir, and I have to move some namespaces around to properly lay them out logically. I'll illustrate the problem below, but TLDR, because Griffe looks for the package in the relative path by default, that interfere with my definitions and causes it to find the wrong definitions (depending on my current directory).

Now, clarifying the situation:

One of the repos, prj_cli, have a module called prj_main.cli.common and a reference to it as ::: prj_main.cli.common. That was a choice of prj_cli team, because its a "shared" plugin in the project and when installed together that makes sense. That worked well while the docs were not aggregated.

But now, they are all built together, and there is indeed a prj_main repository which has its own stuff. When making the aggregated tmpdir, I'm providing a way to merge over these $TMP/prj_cli/prj_main/cli/common to the $TMP/prj_main/ directory, so the reference prj_main.cli.common makes sense. And finally, I'm adding the prj_main tmp 5455 source location to mkdocstrings paths.

That trick is working, unless my CWD is in the true prj_main repository (for example, working on the docs in there), because then Griffe find prj_main in the relative path (and not in /tmp/.../my_prj), which doesn't contain my_prj.cli.common.

Describe the solution you'd like

To have a try_relative_path option in mkdocstring python handler to be passed to griffe.

Describe alternatives you've considered

  • Coordinate with prj_cli team to do it differently.
  • Suggest a change in Griffe so the relative_path is tried as a last resource.

Additional context

I'll happily open a PR.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

    0