Thank you! I realised there was another configuration thing in our setup that was limiting it finding the stubs directory. I resolved that, and -v confirmed that it was at least finding it. The DEBUG log indicated it was skipped because another module took precedence.

I have some follow-up.

We could consider always giving precedence to the stub object (overriding the attribute with the class).

If this is something you're willing to consider, I would be interested in figuring out how to do this. I am up for trying to add the feature myself. That said, I can write basic Python, but I am unfamiliar with the internals of Griffe, and the metaprogramming that seems to be involved with it. This is definitely out of my comfort-zone. Any guidance you could provide would be appreciated.

• writing a Griffe extension that will improve the understanding of these objects statically (for example, for custom decorators, see https://mkdocstrings.github.io/griffe/guide/users/how-to/support-decorators/)

If we can't sort out preferring the stub object, or if for some reason it doesn't work as expected, this seems like a potential alternative. I looked at the linked article. I will almost certainly have questions once I dig into this, but I would like to see about the first option before heading too far into this.

Thank you again!

I am up for trying to add the feature myself

Awesome, thanks a lot for offering your help 🚀

It should be fairly easy, even for someone unfamiliar with Griffe. The relevant code lies here:

https://github.com/mkdocstrings/griffe/blob/723787350171f2c5309ecc97b96f29690756c409/src/griffe/_internal/merger.py#L84-L94

As you see, we're simply comparing the kind of the base object to the stub one, and skipping if it's not the same. We do that because we wouldn't really know how to merge class data into attribute data (or other combinations). But here we want to override, and we know how to do that.

So that small code snippet could be replaced with something like this:

if obj_member.kind is not stub_member.kind:
    obj.set_member(stub_member.name, stub_member)

I'll just have to think about the possible impact of this change, to see if it's good idea generally, or if it could break things.

Would making the change configurable help alleviate the potential for breaking things?

It would, but it's always best to limit the number of options, especially if one of the two possible values (true/false) isn't actually useful ☺️ Here my intuition is that always overriding makes sense, but I might be forgetting about some cases where it wouldn't.

For reference: PR submitted. mkdocstrings/griffe#422