Should "mayaUSD.mod" set USD environment variables?

[KelSolaar]

Hi,

I see that the "mayaUSD.mod" file is setting various environment variables:

+ USD <USD_VERSION> <PATH_TO_PXR_USD_DIR>
PYTHONPATH+:=lib/python
PATH+:=bin
PATH+:=lib

I think it would be better for studios pipeline management toolset to define that instead of the maya-usd plugin, it would make things more portable and self-contained.

As an example, using Rez, USD will typically be required by the maya-usd plugin and the $PATH and $PYTHONPATH variables will be set accordingly AND dynamically, i.e. resolved at require time, which means we can put USD in various locations.

Cheers,

Thomas

[HamedSabri-adsk]

Good point. I have never used Rez so I can't really comment on that. Using the Maya module file that we provide is optional and it is up to the users if they want to use it or not. I should also admit that there are some gotchas with Maya's modules files that is a bit annoying when dealing with them.

[KelSolaar]

Rez was just an example really. One suggestion I could make, however, would probably for AD, The Foundry & the other software vendors and developers to maybe discuss with the VFX studios about how they are configuring their environments and packages. It would highlight the fact that:

• We are all using something like Rez.
• Pipeline maintainers in the VFX studios are likely to never use the various provided build scripts and will have to come up with something that integrates with the local build system.
• Ensuring that building with CMake works while providing hooks in the CMake modules to configure the various library and include paths is extremely warranted!

[rhaleblian]

I generally agree with @KelSolaar. build.py is a good reference for what the CMake invocation expects, and works for initial experiments, but DA (Disney Animation) will have to code site specifics into CMake configuration in the end.

DA doesn't use Rez, but if many people do, we might move to be more compliant with Rez' paradigm so we're all pretty close to a working setup.

DA's build system can cope with Maya module files, I will be attempting to use one here. Failing that, there is a strictish install structure at this site.

[fowlertADSK]

Hey @KelSolaar. Just going through some older open issues and wondering if there was still anything left to answer here? I think the .mod file is generated by the build to help users get it working in Maya but should be completely optional, and if I’m understanding things correctly, shouldn’t interfere with using something like rez. If that’s the case then are we good to close this issue?

[KelSolaar]

Hi @fowlertADSK,

As far as I can tell, and looking at https://github.com/Autodesk/maya-usd/blob/dev/mayaUSD.mod.template, we are not good!

The issue is not with generating a .mod file, quite the opposite and it is actually great to have one. The problem is that the current .mod file tries to do too much. It should only be concerned by the maya-usd module itself, not by any of its external dependencies and thus it should not set any of the USD related variables.

Cheers,

Thomas

[KelSolaar]

Also, note that @rhaleblian has the same requirements as per his comment:

As discussed in #22, i prefer not having USD specifications in here but can't take that out without breakage ATM.

[fowlertADSK]

Thx for the quick reply! I'll log something on our end and see if there is a better approach. I'll leave this one open but probably slap an "enhancement" label on it.

[KelSolaar]

You are welcome!

Removing the USD configuration lines is the proper approach for studios having an environment resolver (which tends to be the norm today). It is really about separation of concerns and encapsulation.

[kxl-adsk]

@KelSolaar I'm wondering how we should proceed with this one. If someone is building maya-usd using build.py, then highly likely he will need the mod file we are generating currently. I see your point about studios with an environment resolver. Would splitting one mod file into two (USD and Maya-USD) would work? (FWIW. we can as well separate mtoh and put into a separate mod file)

[KelSolaar]

I'm a bit out context as I'm at home but I think that having a separate mod file would help! Worse case it would simply mean culling the USD one upon building and no more patching, the former being much easier than the latter.

[kxl-adsk]

Converting this issue to discussion since we are still exploring possibilities. Once we decide on how to address the main concern, we can create a new issue.