Truthfully, I patched up until i found the warning I was getting, and stopped. This could be more extensive, but I probably don't have the time to go through this all.

Not going to lie (and I say this because you've been involved with vispy for so long), this is ugly. That said, I understand the need for it.

What are the difference cases for the different stack levels that _stacklevel_increment would be 0 or 1 or 2 (I assume we don't need more than 2)?

If we assume users aren't using gloo-level classes directly then would _stacklevel_increment being hardcoded to 1 serve most purposes so we can then get rid of the kwarg?

@brisvag thoughts?

Yeah, I'm not a huge fan either... Is it problematic to just always point the max amount of levels up in the "public" api?

Yeah, I'm not a huge fan either... Is it problematic to just always point the max amount of levels up in the "public" api?

You can do that if you can figure out where the public API boundary lives.

Is this idea too insane? It looks for the nearest stack frame that points to a file outside the vispy search path. It takes ~0.3 ms for the first execution and is ~10x faster for subsequent calls.

def _get_user_code_stacklevel():
    import vispy
    import traceback
    stack = traceback.extract_stack()
    for level, frame in enumerate(stack[::-1]):
        if not frame.filename.startswith(vispy.__spec__.submodule_search_locations[0]):
            break
    return level

Besides whether it is valid or not, would it make sense to remove the "not" and return the level inside the if statement?

You mean walk the stack in the other direction?

No. I mean I don't think "break" is necessary. You could just put the return there instead of breaking. I'm not sure what I was thinking when I said to remove "not", ignore that.

Ohh, I see. Yes. You're right. The only difference is if it never finds a stack frame with a file outside the vispy path, it would return None where as-is it would return the max stack level. I don't think that would generally happen though because as far as I know vispy is always used as a library not an application.

Yeah, leave it as is.