| Finally getting back to this. Appreciate all the pointers.
Cheers,Greg
On Tue, May 30, 2017 at 4:50 PM, Matt Plec <mplec@mplec.com> wrote:
Hey Greg --
I'm not much of a maya guy but Andry Jong introduced me to modules and with the decent autodesk docs on them it's been easy enough to manage that way for our simple setup supporting just a few maya artists. One of the nice features is you can set/append environment variables in the .mod file which isolates a lot of the cruft if you don't have wrapping to manage that. The only (maya-specific) one I've found I've still got to set outside of the module is MAYA_RENDER_DESC_PATH. Those files seem to be needed before the modules get (completely?) handled. Also, you can support different platforms within a single .mod file which has been convenient for our "un-wrapped" setup.
I should reiterate that our setup is really simple because right now it can be, with just a few artists on Windows, a little bit of linux rendering, and work that doesn't require project lock-offs, etc. When we outgrow this it'll be time for some kind of wrapping like JF's suggesting. (If you're already there, check out http://github.com/nerdvegas.) In the meantime, we're structuring all the tools in a way that will work in a proper version-managed environment to make future migration easier.
I tend to install the Windows maya plugins first the "normal" way since that often seems like the only way to get the files unpacked at all. Then I copy the install to our network location and version naming/organization, uninstall the local install, and make a .mod file (or update the old one). I'm putting all the .mod files in a versioned tool dir just like any other tool/plugin. This way we just have one env var to worry about, the MAYA_MODULE_PATH, with the path to the current (or a chosen version) of a package of .mod files to use. (Time to re-re-iterate that this won't scale -- but it's as much overhead as our complexity demands right now.)
Here is our current package of .mod files in case some reference is useful:
---- tools/nvr_maya_modules/1.2.0/alShaders.mod+ MAYAVERSION:2017 PLATFORM:win64 alShaders any Z:\tools\alShaders\1.0.0rc19-ai4.2.12.2MTOA_TEMPLATES_PATH +:= win-x86_64\aeMAYA_CUSTOM_TEMPLATE_PATH +:= win-x86_64\aexml
+ MAYAVERSION:2017 PLATFORM:linux alShaders any /nextvr/tools/alShaders/1.0.0rc19-ai4.2.12.2MTOA_TEMPLATES_PATH +:= linux-x86_64\aeMAYA_CUSTOM_TEMPLATE_PATH +:= linux-x86_64\aexml
---- tools/nvr_maya_modules/1.2.0/deadline.mod+ MAYAVERSION:2017 PLATFORM:win64 deadline any Z:\tools\deadline\current\maya
---- tools/nvr_maya_modules/1.2.0/mtoa.mod+ MAYAVERSION:2017 PLATFORM:win64 mtoa any Z:\tools\mtoa\2.0.0.0\maya-2017\win-x86_64PATH +:= binMAYA_CUSTOM_TEMPLATE_PATH +:= scripts/mtoa/ui/templatesMAYA_SCRIPT_PATH +:= scripts/mtoa/melMAYA_RENDER_DESC_PATH +:=
+ MAYAVERSION:2017 PLATFORM:linux mtoa any /nextvr/tools/mtoa/2.0.0.0/maya-2017/linux-x86_64PATH +:= binMAYA_CUSTOM_TEMPLATE_PATH +:= scripts/mtoa/ui/templatesMAYA_SCRIPT_PATH +:= scripts/mtoa/melMAYA_RENDER_DESC_PATH +:=
---- tools/nvr_maya_modules/1.2.0/nvr_maya_common.mod+ PLATFORM:win64 nvr_maya_common 1.0.0 Z:\tools\nvr_maya_common\1.0.0+ PLATFORM:mac nvr_maya_common 1.0.0 /Volumes/nextvr/tools/nvr_maya_common/1.0.0+ PLATFORM:linux nvr_maya_common 1.0.0 /nextvr/tools/nvr_maya_common/1.0.0
---- tools/nvr_maya_modules/1.2.0/pedrofe_vr_camera.mod+ MAYAVERSION:2017 PLATFORM:win64 pedrofe_vr_camera any Z:\tools\pedrofe_vr_camera\current\arnold-4.2.14.4MTOA_TEMPLATES_PATH +:= win-x86_64\ae
+ MAYAVERSION:2017 PLATFORM:linux pedrofe_vr_camera any /nextvr/tools/pedrofe_vr_camera/current/arnold-4.2.14.4MTOA_TEMPLATES_PATH +:= linux-x86_64\ae
---- tools/nvr_maya_modules/1.2.0/zync_maya.mod+ MAYAVERSION:2017 PLATFORM:win64 zync_maya any Z:\tools\zync_maya\1.2.17PYTHONPATH += Z:\tools\zync_maya\1.2.17XBMLANGPATH += Z:\tools\zync_maya\1.2.17
+ MAYAVERSION:2017 PLATFORM:linux zync_maya any /nextvr/tools/zync_maya/1.2.17PYTHONPATH += /nextvr/tools/zync_maya/1.2.17XBMLANGPATH += /nextvr/tools/zync_maya/1.2.17
On Tue, May 30, 2017 at 10:05 AM, Dan Young <dan.robert.young@gmail.com> wrote:
There are few things posted in this mailing list that I agree with more than what JF just said. Hats off.
DY
On Tue, May 30, 2017 at 12:25 PM, Jean-Francois Panisset <panisset@gmail.com> wrote:
Maya plugins are kinda gross in general, most of them can usually be beaten into submission not to install into Maya installation directories via environment variables or hacking the MEL source, but it's a case-by-case situation.
I would strongly suggest you bite the bullet now and write a startup wrapper that is version aware: Maya versions come fast and furious, and you often end up with versions that fix important things yet break others, so locking Maya versions on a per-project basis quickly becomes a requirement.
JF
On Tue, May 30, 2017 at 5:48 AM, Greg Dickie <greg@justaguy.ca> wrote:
Hey Todd,
Just getting back to this. I guess I have a simpler case. We only support maya on linux and likely only one version at a time. No wrapper scripts but running shotgun desktop. The plugins are really the issue, instructions to copy this file in the maya tree and this file into a user's directory. Horrible. I'll check out modules.
Thanks for the advice,Greg
On Wed, May 24, 2017 at 10:22 AM, Todd Smith <todd@sohovfx.com> wrote:
I could blather on about this all day.
Are you supporting multiple Maya versions across multiple OS's? Do you have any wrapper scripts that are currently used to launch Maya or any other application?
There are definitely ways of centralizing, modules make centralization a breeze (definitely read up on them if you haven't already), however there are still a tonne of plugins that assume a single user, single version of Maya philosophy.
If you don't have your own wrapper script system, then I would recommend taking a look at Peregrine Labs Ecosystem code on Github.
Todd Smith
Head of Information Technology
soho vfx|99 Atlantic Ave. Suite 303, Toronto, Ontario M6K 3J8office:(416) 516-7863fax:(416) 516-9682web:sohovfx.com
From: "Greg Dickie" <greg@justaguy.ca>
To: "studiosysadmins-discuss" <studiosysadmins-discuss@studiosysadmins.com>
Sent: Wednesday, May 24, 2017 9:16:42 AM
Subject: [SSA-Discuss] Best practices for deploying maya
Hopefully there are still some people left on email ;-)
I'm having to deal with maya on linux these days and struggling a little bit with the best way to deploy it and all the plugins, modules, shelves, etc it requires. A bunch of the plugin installation instructions talk about copying files into the maya directory tree. That seems like a bad idea to me. The various MAYA_*_PATH variables also seem pretty limited.
My question is has anyone mastered this and/or is there a best practices guide that already exists for this? Are there downsides to deploying on a network share versus locally? Is thee a way to centrally manage all the various plugins,modules,shelves?
Thanks,Greg
--
Greg Dickie
just a guy514-983-5400
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
--
Greg Dickie
just a guy514-983-5400
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
--
Greg Dickie
just a guy514-983-5400
| |
|
