Yesterday I learned that there is another way of executing scripts on start-up besides usersetup.py and usersetup.mel. If you create a Maya Module (for example “TestModule”) and add a mel file in the scripts folder caller “_load.mel” (so “TestModule_load.mel”) it will be execute as on start-up like a usersetup.mel. The Maya BonusTools work that way. I did not find any documentation on that, so I thought I’d share it here and see if anybody else has seen this or might have more info on that.
I already posted this in the Tech-Artist Slack channel and we found that this might be a potential security issue. So I’d thought to post it here as well so it gets some exposure.
Cheers,
Fabian
PS: If that would be an official documented feature I would actually kinda like it, since it would not interfere with the usersetup.mel and would make more sense naming wise inside a Maya module.
Maya modules are the main way that packages (like bonus tools, Bifrost, so many…) are distributed, since each one can have it’s own unique userSetup.mel/.py that don’t conflict with any others.
It’s how I manage my studio’s Maya tools, and makes it easy to fold in anything else from the internets / other studios.
I think the main purpose of the post was to inform about the seemingly undocumented “feature” of Maya modules to execute a file matching the module_name + _load.mel on startup as userSetup does.
This could be important for security features for example.
I think the main purpose of the post was to inform about the seemingly undocumented “feature” of Maya modules to execute a file matching the module_name + _load.mel on startup as userSetup does.
This could be important for security features for example.
LOL, I totally missed that: I think I read ‘Maya Module’ (instead of mel script), and my brain went that direction.
Some casual testing here suggests that maya 2022+ may be disabling separate userSetups in modules but the xxx_load.py method still works. Not sure how to interpret this but worth knowing.
Moreover the xxx_load.py mehod bypasses the userSetup checksum test: In this example I changed both a userSetup.py (which did not actually execute!) and a xxx_load.py (which did) and the security message only caught the first: