Preventing issues between a DCC's built binaries and the `usd-core` python wheel

Community Build and Deployment
1

Is it possible for a DCC’s python environment, with its own USD binaries and integration, to play nice if users happen to also install the external usd-core python package? A variety of gnarly libc crashes result currently.

Is this a case where we, the DCC, should use a custom PXR_SET_INTERNAL_NAMESPACE build option? Or in what way might this be supported?

2

I think the only way is to set the custom namespace. It’s what we do for our OS products to prevent conflicts with whatever a user may build/provide themselves.

3

One concern with using a custom namespace, its makes it more cumbersome for studios/pipelines/plugin providers to integrate their USD tooling into your DCC. It will mean they need to custom compile their entire stack, as opposed to a (sometimes simple) drop-in of existing binaries.

I have also hit this “users happen to also install the external usd-core python package” issue and its caused confusion with my libraries. I’d heard (from more pythonic folks than myself) that it would be a bit bizarre for people to pip install usd-core outside of a virtual environment, but in practice it does seem to happen…

Do we know what causes both binaries to load at runtime? If it is “first one wins” then I would think the DCC should be able to setup its paths / env vars such that its binaries always list first.

4

Yeah, in this case it’s “whoever loads second encounters a nonsensical crash inside the Tf_DebugSymbolRegistry::Tf_DebugSymbolRegistry() call path”.

The issue you mention with setting a custom ns I hadn’t considered. The full context here that I didn’t mention is that, for the current case, the DCC itself is loaded as a module too – all inside a venv:

  • Create a python venv
  • Pip install “dcc_module”
  • Pip install “usd_core”
  • Run python
  • Scenario 1
    • import dcc
    • from pxr import Usd
    • Crash with a stack emanating from usd_core
  • Scenario 2
    • from pxr import Usd
    • import dcc
    • Crash with a stack emanating from dcc_module

Do we just throw in the towel and say “not supported”?

5

Personally I don’t think it’s such a big deal to require people to rebuild against your libs if you do the custom namespace. Chances are they’ll need to do it for other things as well anyway and aren’t sharing a single dylib between multiple apps. There’s very little chance all those apps/contexts even align on the same USD version so won’t have the same namespace anyway.

A custom namespace wouldn’t require them to change their code in anyway, assuming they’re using the included macros versus hardcoding it.

But yes, if you can’t change the namespace you’ll have to tell them it’s unsupported and they’re on their own. This is pretty much the state of any dynamically loaded library in a DCC anyway, such as if someone installs PySide and tries to use it in Maya.

6

Let me float the idea of a custom namespace to our folks. There’s some other gotchas that we have to sort out as well regardless.

In other hilarious news, in between the time when I last installed usd-core and today, they moved from 2405 to 2408. This would have presented the perfect opportunity to observe if the namespace is really the problem since the DCC in question is using 2405. Unfortunately the patch version is not part of the current namespace womp womp :slight_smile: I see you: Apple: Include the USD patch version in the namespace by dgovil · Pull Request #3167 · PixarAnimationStudios/OpenUSD · GitHub

7

Yep, 24.11 onwards will have it in.