# Preventing issues between a DCC's built binaries and the \`usd-core\` python wheel **URL:** \ **Category:** Build and Deployment\ **Created:** [October 9, 2024, 6:53am UTC](https://forum.aousd.org/t/preventing-issues-between-a-dccs-built-binaries-and-the-usd-core-python-wheel/1904 "2024-10-09T06:53:07Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![deadpin](https://avatars.discourse-cdn.com/v4/letter/d/43a26b/32.png) [@deadpin](https://forum.aousd.org/u/deadpin)\ **Post date:** [October 9, 2024, 6:53am UTC](https://forum.aousd.org/t/preventing-issues-between-a-dccs-built-binaries-and-the-usd-core-python-wheel/1904/1 "2024-10-09T06:53:07Z")
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? ---
**Author:** ![dhruvgovil](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/dhruvgovil/32/3_2.png) [@dhruvgovil](https://forum.aousd.org/u/dhruvgovil)\ **Post date:** [October 9, 2024, 2:41pm UTC](https://forum.aousd.org/t/preventing-issues-between-a-dccs-built-binaries-and-the-usd-core-python-wheel/1904/2 "2024-10-09T14:41:20Z")
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. ---
**Author:** ![andrew](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/andrew/32/130_2.png) [@andrew](https://forum.aousd.org/u/andrew)\ **Post date:** [October 9, 2024, 4:10pm UTC](https://forum.aousd.org/t/preventing-issues-between-a-dccs-built-binaries-and-the-usd-core-python-wheel/1904/3 "2024-10-09T16:10:31Z")
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. ---
**Author:** ![deadpin](https://avatars.discourse-cdn.com/v4/letter/d/43a26b/32.png) [@deadpin](https://forum.aousd.org/u/deadpin)\ **Post date:** [October 9, 2024, 4:57pm UTC](https://forum.aousd.org/t/preventing-issues-between-a-dccs-built-binaries-and-the-usd-core-python-wheel/1904/4 "2024-10-09T16:57:00Z")
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”? ---
**Author:** ![dhruvgovil](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/dhruvgovil/32/3_2.png) [@dhruvgovil](https://forum.aousd.org/u/dhruvgovil)\ **Post date:** [October 9, 2024, 10:47pm UTC](https://forum.aousd.org/t/preventing-issues-between-a-dccs-built-binaries-and-the-usd-core-python-wheel/1904/5 "2024-10-09T22:47:58Z")
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. ---
**Author:** ![deadpin](https://avatars.discourse-cdn.com/v4/letter/d/43a26b/32.png) [@deadpin](https://forum.aousd.org/u/deadpin)\ **Post date:** [October 10, 2024, 12:10am UTC](https://forum.aousd.org/t/preventing-issues-between-a-dccs-built-binaries-and-the-usd-core-python-wheel/1904/6 "2024-10-10T00:10:00Z")
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 🙂 I see you: [Apple: Include the USD patch version in the namespace by dgovil · Pull Request #3167 · PixarAnimationStudios/OpenUSD · GitHub](https://github.com/PixarAnimationStudios/OpenUSD/pull/3167) ---
**Author:** ![dhruvgovil](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/dhruvgovil/32/3_2.png) [@dhruvgovil](https://forum.aousd.org/u/dhruvgovil)\ **Post date:** [October 10, 2024, 12:13am UTC](https://forum.aousd.org/t/preventing-issues-between-a-dccs-built-binaries-and-the-usd-core-python-wheel/1904/7 "2024-10-10T00:13:49Z")
Yep, 24.11 onwards will have it in.