I have a library that links against USD that is then wrapped in Python (but does not itself use the USD python bindings). When I import my library into a python process I get warnings from USD for each module like:
Warning: in _LoadLibModules at line 329 of /tmp/rez-cook/usd/25.08/pxr/base/tf/scriptModuleLoader.cpp -- Error loading lib ar's module 'pxr.Ar':
ModuleNotFoundError: No module named 'pxr'
...
Warning: in _LoadLibModules at line 329 of /tmp/rez-cook/usd/25.08/pxr/base/tf/scriptModuleLoader.cpp -- Error loading lib work's module 'pxr.Work':
ModuleNotFoundError: No module named 'pxr'
is there a way I can stop this from happening without completely disabling python support in the original USD build (in the general case I can’t control the build of the USD libraries I’m linking against)
Short answer is you can’t stop _LoadLibModules from being called in a python-initialized process without disabling python in the OpenUSD build.
To determine if the errors are unexpected and what you might do about them, can you say what your platform is, what flavor OpenUSD build you did (and expect going forward, i.e. static/dynamic, monolithic or not), and whether the OpenUSD build has been relocated from where it was originally installed by the build?
Thanks Spiff. I guess I could use TfErrorMark etc to explicitly swallow those (and probably parse them to not ignore other errors that might have happened during init).
I think they’re expected - I’m not using the same python that USD was built against, so adding USD’s python modules to PYTHONPATH would be a bad idea.