# Deploying MaterialX libraries with usd based application **URL:** \ **Category:** Build and Deployment\ **Created:** [January 4, 2024, 9:43pm UTC](https://forum.aousd.org/t/deploying-materialx-libraries-with-usd-based-application/1090 "2024-01-04T21:43:26Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![laserallan](https://avatars.discourse-cdn.com/v4/letter/l/dc4da7/32.png) [@laserallan](https://forum.aousd.org/u/laserallan)\ **Post date:** [January 4, 2024, 9:43pm UTC](https://forum.aousd.org/t/deploying-materialx-libraries-with-usd-based-application/1090/1 "2024-01-04T21:43:26Z")
When building USD with MaterialX my current understanding is the plugin looks for the standard library in the following locations: 1. The locations pointed out by: PXR\_MTLX\_PLUGIN\_SEARCH\_PATHS 2. The locations pointed out by the environment variable: PXR\_MTLX\_STDLIB\_SEARCH\_PATHS 3. The locations fed in by the compile time defined value of PXR\_MATERIALX\_STDLIB\_DIR What they all have in common is that they are (as far as I understand them) absolute locations that needs to be specified either by the system or at compile time. In order to build an application using USD I’d prefer to look up these things relative to the install location in some form. My instinct would be to store and install the MaterialX library as resources in the UsdMtlx plugin resource directory and use that as the fallback location if everything else fails to make sure any valid build of usd relocated or not has the standard library available. What are your thoughts on this topic? I get the feeling the current setup is very one environment for everyone oriented and not very application oriented. Also, please challenge my assumptions, is there a way of loading the materialx libraries from a location relative to the installed application. I am aware it’s possible to set the environment variables inside the process to work around this but I’d rather avoid that solution unless I have to. ---
**Author:** ![koen](https://avatars.discourse-cdn.com/v4/letter/k/a9a28c/32.png) [@koen](https://forum.aousd.org/u/koen)\ **Post date:** [January 5, 2024, 5:26pm UTC](https://forum.aousd.org/t/deploying-materialx-libraries-with-usd-based-application/1090/2 "2024-01-05T17:26:59Z")
I might misunderstand, but we have had issues with something like this for usd itself as well, where you need to set the PXR\_PLUGINPATH\_NAME. I’d love all these libraries to have a fallback to some location relative to the application, so you could theoretically install without any env vars. ---
**Author:** ![laserallan](https://avatars.discourse-cdn.com/v4/letter/l/dc4da7/32.png) [@laserallan](https://forum.aousd.org/u/laserallan)\ **Post date:** [January 5, 2024, 5:38pm UTC](https://forum.aousd.org/t/deploying-materialx-libraries-with-usd-based-application/1090/3 "2024-01-05T17:38:27Z")
That is what I want to get to too. In its condensed form: If I want to build a relocatable usd application with the materialx plugin, how do I distribute the materialx libraries properly? As an extreme example, imagine distributing usd with the materialx plugin as a python pip package and make it work without the user having to make additional API calls. The only way I could get it to work today as far as I understand it would be to somehow hack an **init**.py somewhere to sneak in some data into the environment since I don’t have control over the python interpreter which would be analogous to where I would do that myself if building my own application. ---
**Author:** ![laserallan](https://avatars.discourse-cdn.com/v4/letter/l/dc4da7/32.png) [@laserallan](https://forum.aousd.org/u/laserallan)\ **Post date:** [January 6, 2024, 1:04am UTC](https://forum.aousd.org/t/deploying-materialx-libraries-with-usd-based-application/1090/4 "2024-01-06T01:04:49Z")
Here is a proposed solution: > > > \### Description of Change(s) > > This PR tries to make distribution of the Materi…alX standard library relocatable > for usdMtlx. > This allows an application to find the MaterialX standard library relative to the plugin's > installed location rather than rely on system wide environment variables or paths burned > into the plugin library at compile time > > It implements it by > > \* Installing the MaterialX standard library as resources in the usdMtlx plugin. > \* Adds a lowest priority search path for materialx libraries pointing to the > resource location of the plugin > > \### Fixes Issue(s) > Distribution of materialx applications that can't rely on system environment variables > for the MaterialX standard library > > \