So I got a message from a user on Thursday saying that cgmToolbox didn’t work in Maya 2017. Got around to installing 2017 and yup – borked. Spent the evening on Thursday identifying this issue and Friday was fix day.

If you don’t care about what was wrong and just want the bottom line — cgmToolbox should be working in 2017 Maya with the new build I’ll be pushing to the repository shortly.

If you do care…

NOTE – If you use use zooToolbox and specifically zooPy.path.Path (or zoo.Path as I’ll call it), this post would behoove you to look at unless you like stumbling down the same rambling trail others have tread.

Been using zoo stuff for well over 5 years now and Hamish(creator of zooTools) is out of the game last I knew so I decided I had best fix the problem as googling the topic got jack squat and my usual sounding boards hadn’t come across it yet.

Initially I thought Autodesk had gone and changed something and blew up my stuff but at the end of the day it turned out to be the fact that the python that 2017 is running updated the python str class. It just so happens that zoo.Path runs that as a subclass and was overloading some built in calls (find and replace specifically). Anyway, there is a walk generator for path stuff that pushing an instance of the zoo.Path into it rather than a ‘native’ string. Part of that (new to 2017) walker calls on ‘replace’ and so breaks because it needs to replace the path separator which zoo.Path specifically avoids in it’s overload. zoo.Path’s replace is ONLY for replacing tokens between the separators.

Long story short, that raises an error of ‘/’ cannot be indexed because the find call (in zoo.Path) is specifically removing in it’s searching.

Interesting tidbits:

With 2017, os.path.sep is now ‘\\’ up till 2017, it’s been ‘\’ at least all the way back to Maya 2011. On windows at least

Something changed with the os.walk generator to make it not work as it did before 2017. Maybe it used to str(arg) stuff in the process and now just passes through the string. Whatever the reason, it broke.

zooPy.path.Path — If you have old versions of zoo installed and trying to run stuff in 2017. It’s gonna break on you if it hasn’t already. You can use this or do your own patch:)

osPath — call to return a os.path.sep joined version of the path. Path natively works with ‘/’ and the new double ‘//’ messes with stuff

_list_filesystem_items — changed the walk creator to use a osPath string to stop the failing

Cleaned out a bunch of stuff from __init__ files. — I’d had some built in calls for listing files and getting other info back before I knew the right way to do it or at least a better one.

cgmToolbox

clean_scriptPaths/clean_pluginPaths — The call that was breaking stuff were my path setup stuff. As such, the env for these guys got a little borked during the troubleshooting. This was a quick attempt at fixing stuff. As an experiment, this may or may not be reworked.

Check all paths for valid paths (will add to the env without failing)

Removed a bunch of .git stuff that some other scripts I’d used from someone else apparently added.

Acts as a report for what’s there if you didn’t know as it reports all good ones

core.cgmPy.os_Utils

get_lsFromPath — reworked from the __init__ cleanup. Accepts file paths now and just gets the director they’re in for searching

Now I can get back to cgmBlendshape for Morphy 2. Wrote some fun mesh math stuff toward that end earlier in the week as well but that’s a post for another day…:)

So, a chat with a good buddy (Scott Englert) on the topic brought up one more item I’d neglected to rule out in the previous bit of research.

Flush prefs.

Dur…

So I did and the issue vanished, which led me to delve into what script or preference was causing issues. Did this by re-adding files and scripts to figure out what it was. As it happens it wasn’t a specific file but an import that did it. In the end, I found 2 issues at play – one of which is solved but broke my unit tests so I’m waiting to for Red9 to figure out how to resolve. In this case it was registering ‘transform’ as a nodeType in r9Meta stuff in one of my __init__ files.

r9Meta.registerMClassNodeMapping(nodeTypes = ['transform'])#...stupid line of code!

Hopefully finding this will make the red9 stuff which we love all the better once it’s resolved and keep others from bounding into the time sucking vortex that resulted.

Lesson learned – if something is acting weird, clear prefs and see if it fixes it and if it does, start adding stuff back till you find the culprit.