command-line interface for the installer

[BeardedPlatypus]

Is your feature request related to a problem? Please describe.

We are building a Maya plug-in on top of Maya-USD. In order to easily distribute this plug-in to internal users we would like the option to automatically install the correct version of Maya-USD for them. Currently, Maya-USD only seems to be distributed as a executable without any command-line interface (CLI), making it impossible to use the installer directly to automatically install Maya-USD without user interaction.

Describe the solution you'd like

We would like to have an installer that provides some basic CLI (e.g. like this), which would allow us to install the Maya-USD plugin without requiring user intervention.

Describe alternatives you've considered

Currently, we work around this problem by installing the plugin locally then creating a new archive which is hosted internally. This archive can then be retrieved and configured using the MAYA_MODULE_PATH environment variable. This seems to work, however it does require some maintenance when we want to update to a newer version of Maya-USD

Alternatively to a CLI for the installer, just having the compiled plugin as a .zip archive added to the release would also be sufficient for our current needs.

Additional context

I understand this might not be a high-priority issue, but it would be a very welcome quality of life improvement which would simplify our distribution system significantly.

If there are other ways to distribute this easily, I would gladly welcome any suggestions as well!

[santosg87]

hi @BeardedPlatypus. thank you for the suggestion! i will bring this up with the team.

for the time being, though there might an option for you, although a bit of a long workflow:

• you can use something like 7-zip to extract the contents of the *.exe installer.
• with the contents extracted, you should now be able to run the *.msi file ** with the msi file, you should also be able to run the Msiexec command from the command line. - note that you will need to run the CLI with admin rights in order to install the package. :)

[paulgolter]

Hey @santosg87 @BeardedPlatypus ,

I am having the same issue right now. In our facility we need to update all machines with the latest maya usd plugin.

Is it somehow possible to install the plugin via some environment variable options? Meaning if I installed the plugin locally on one machine, can I copy the contents of e.G

C:\Program Files\Autodesk\MayaUSD\Maya2023\0.24.0_202306271239-a402544

To some centralized place and load it from there?

[BeardedPlatypus]

Hi @paulgolter

That is basically how we solved it for the time being. We have one person install the plug-ins locally, then we zip-up the contents of those folders (for the Maya versions we support in our pipeline). These zip files are uploaded to a centralized server. In our set-up, these zip files are downloaded on the artists machines and we basically start Maya where we add the location of the downloaded unzipped maya-usd directory to the MAYA_MODULE_PATH environment variable. This will ensure Maya can find the Maya-USD plug-in.

If the path to the parent directory of the .mod file is in the MAYA_MODULE_PATH it will be available in the plug-in manager.

If this is what you mean by having it in a centralized place it would work. You would still need to download it on the machines to some location. I haven't tried having some shared NAS-like solution for it or anything.

[paulgolter]

Hey @BeardedPlatypus thanks for the quick reply!

I tried your approach and it seems to work! The only thing I am worried about is that maya seems to already have a list of search paths as a "base" value for MAYA_MODULE_PATH. If I set this env variable before starting maya, the base value is appended in the end.

Therefore the default install location of the maya usd plugin (the older version that ships with maya) is also in the MAYA_MODULE_PATH but comes after my custom defined path.

It seems like Maya loads the module from the first search path and ignores the second one, which is what I want.

Now I am not sure if at any point this would clash with each other or if Maya will basically omit any modules if they are already loaded by a previous search path, even if the module version might be a different one.

[BeardedPlatypus]

(I'm not affiliated with Autodesk in anyway, most of my knowledge has been gained over the past year, so take whatever I write here with a grain of salt. If anyone can correct me, please do)

As far as I know, the internal plug-in resolve method within Maya will look at the version defined in the .mod file and when there are duplicate plug-ins (i.e. with the same name in the .mod file), it will only load/show the latest in the plug-in manager. So your newer maya-usd will be loaded as the version is greater than the default one.

You are right though, that there could be default values (or values set by artists themselves). In order to handle this, we only append to this environment variable (if it exists). That way we don't accidentally remove other plug-ins from the plug-in manager that were defined in this path.

I believe the default paths maya checks is the %HOME%\Documents\maya\<maya_version>\modules. So if you didn't want to use the MAYA_MODULE_PATH you could probably also get away with making symlinks to there. However for us the environment variable worked well enough.

[paulgolter]

Hey @BeardedPlatypus

Thanks for sharing your experiences. Yes I can confirm what you wrote. At least in my case I can see I have both versions of the maya-usd plugin in the MAYA_MODULE_PATH but it uses the latest one that I added to MAYA_MODULE_PAT before starting maya.

[seando-adsk]

FYI, you can set the env var "MAYA_MODULE_DEBUG" which will output all sorts of debugging information in the Output Window when parsing/loading the module files. If you have duplicate modules you will see which one it loaded and which one it skipped.

Basically Maya will search thru the paths set in MAYA_MODULE_PATH. You can see what this var contains by running getenv "MAYA_MODULE_PATH" in the Script Editor. This will contain any paths you explicitly set (by setting this env var) and also the paths that Maya will add at startup.

When a module conflict is encountered there are two things checked: priority and version. The priority is the order of the MAYA_MODULE_PATH with paths searched first having higher priority. This means the module you add (by setting MAYA_MODULE_PATH) should be the one used since it will come before the paths Maya adds to MAYA_MODULE_PATH.

Sean

[LucaScheller]

hi @BeardedPlatypus. thank you for the suggestion! i will bring this up with the team.

for the time being, though there might an option for you, although a bit of a long workflow:

• you can use something like 7-zip to extract the contents of the *.exe installer.
• with the contents extracted, you should now be able to run the *.msi file ** with the msi file, you should also be able to run the Msiexec command from the command line. - note that you will need to run the CLI with admin rights in order to install the package. :)

Hi, thanks for the tip on how to work around this on Windows. Is there a way to do the same thing on Linux for the .run file? I've been having no luck with 7-zip there (maybe I am passing in the wrong flags) or with trying to subprocess stdin accept the Eula.

Any help would be appreciated :) Cheers, Luca

[LucaScheller]

Notes: @santosg87 Forwarded me to this post for the solution: https://github.com/Autodesk/maya-usd/issues/2681#issuecomment-1341486687

So we have working workarounds for Windows and Linux for now, thanks a lot!