Fri, Sep 2nd, 2016
posted by jjburton 09:09 PM

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.
  • import sys || sys.version — gives you your python version. If you’re curious 2017’s is 2.7.11

Some code changes

  • 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…:)


Mon, Mar 2nd, 2015
posted by jjburton 01:03 PM

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.


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.

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.


Thu, Nov 1st, 2012
posted by jjburton 03:11 PM

We’re trying out the name ProblemKicker. If anyone else had a better one, we’re all ears.

Creative Commons License