At both Lionhead and Improbable we use PyMel heavily. Infact it makes up the majority of our pipeline code. Having an object based wrapper to interface with Maya/Nodes makes coding far easier than dealing with names and strings all the while.
Typically we use it ‘out-the-box’ predominantly and just keep an eye on fixes that are of interest that we cherry pick ( though we honestly didnt have to do that much at all ). If you choose to get a later release or deploy your own custom version its just a case of ensuring your version comes before the default maya one in the sys.path list.
At Lionhead we switched from 2012/2013/2014 with barely any alterations to our actual pymel code (i cant actually recall any).
We tend to fallback to compiled c++ plugins for anything that requires a node that will be used within a rig just to ensure framerates will be as high as possible, and there is the occasional splash of cmds in places ( again usually where you need to iterate through masses of verts etc ).
We’re just building a fresh pipeline at Improbable, and I dont hesitate to use PyMel heavily within the Maya codebase. IMO its a python integration done right.
Pymel is pretty much standard equipment; it’s quite well done (although I’m sure everybody has their quibbles in matters of detail) and can definitely help you write more concise, readable code. Plus the vector and matrix types that come with it are very handy and save a ton of roll-your-own work.
The main drawbacks are the long startup time (universally reviled) and the tight under the hood integration of the Maya API - while using the APIs great for common maya problems (like renaming a bunch of objects without doing lots of fancy footwork to hang on to them as their names changes) it does mean you can also completely crash maya with a typo, which is much harder to do with vanilla cmds.
FWIW if you just want to write pCube1.tx = (1,1,1) you can do that without pymel by using a descriptor that wraps the a native maya command. Here’s an example for working with transforms, it’d be fairly simple to do the same thing for other properties Tech Art Survival Guide: Descriptors and pythonic Maya properties
We use PyMel pretty much exclusively. The one area that I will avoid it (or just use the python API) is when processing large numbers of components. There can be a large overhead when pymel casts thousands of components to individual API types.
There are some annoyances and gotchas when using PyMel that you’ll discover as you work with it (if you haven’t already). Some methods don’t return PyNodes (like filterExpand), and you’ll come across some calls that just plain break (like calling duplicate on a namespaced object when an object with the same short name (non-namespaced) exists, or using slices on a getAttr call for a multiAttr)
EDIT:
Oh and the pymel.util.path module shipped with 2014 breaks on isdir calls (python2.7 changed the isdir implementation, and stopped playing nice with the version of the path module that ships with pymel in 2014). Since then they’ve updated the path module in their repo, but just be aware of that if you’re using 2014 and the path module.
Sounds all good. Looks like no studios try to avoid it.
It will take a while to transfer from our custom node system to PyMel’s, but I believe it will be worth it.
As for deploying a custom version we’ll avoid it as much as possible. Think we’ll have all functionality from the standard out-of-the-box PyMel version. So far no complains…
I like PyMel alot more then maya.cmds. So I’m looking forward to switch