Oh, such a system is in Place - unknown nodes are either of type "Unknown" or "UnknownDag", in case of plugin types, there are plenty of "UnknownPlugin..." type names as well. You ran into a bug related to a type missing in the static portion of the node hierarchy database, and I am glad that this happened now as such an ungraceful import error is quite a bad sign for the quality of software. Although a test exists for the correctness of the node hierarchy, manipulators are left out as they tend to crash maya if created outside the context of a specific tool.
Thanks for bringing this up, Sebastian On Apr 25, 9:29 pm, Judah Baron <[email protected]> wrote: > Great! Thanks for the response. We are not loading anything with a > custom manipulator, but I'll turn things off to see what happens. > > Question: > If mrv does find something that it doesn't recognize is it possible to > fail more gracefully? So instead of failing to load, could that > nodetype just not be tracked/supported by mrv? Maybe such types could > be wrapped with something like a safeUnknown interface that would be > consistent with the general class generation paradigm already in > place, but would generate something that the user/developer could then > use to investigate the problem, should it become apparent. > > Thanks again, > -Judah > > On Sun, Apr 25, 2010 at 8:09 AM, Sebastian Thiel > > > > <[email protected]> wrote: > > Hi Judah, > > > Please pull the master branch on gitorious or github for a potential > > fix. Its just a potential one as I have had no way to reproduce the > > issue, although I believe to know what is happening there. > > > Apparently you have a plugin loaded that is registering a plugin > > manipulator. As a quick workaround and verification, try to import MRV > > without that plugin being loaded. > > The reason for the failure is that the node hierarchy does not contain > > the plugin node type called "UnknownPluginManipContainer" which MRV > > uses to classify these custom manipulators. The reason for that was a > > bug in the node hierarchy creation procedure which is now fixed. Using > > that fix, I recreated the type hierarchy which now includes the > > missing type, hence the initialization should be fine with the latest > > version. > > > Please let me know whether it works for you, > > Sebastian > > > On Apr 23, 8:06 pm, Judah Baron <[email protected]> wrote: > >> I am looking at MRV and I like what I see so far, although I am getting an > >> UnknownPluginManipContainer upon import. > > >> Any idea what this means? > > >> import mrv.maya.nt > >> # Error: ('UnknownPluginManipContainer',) > >> # Traceback (most recent call last): > >> # File "<maya console>", line 1, in <module> > >> # File > >> "C:\dev\projects\Main\TnT\Tools\sdk\python\Lib\site-packages\mrv\maya\nt\__init__.py", > >> line 365, in <module> > >> # _init_plugin_db() > >> # File > >> "C:\dev\projects\Main\TnT\Tools\sdk\python\Lib\site-packages\mrv\maya\nt\__init__.py", > >> line 189, in _init_plugin_db > >> # pluginDB = PluginDB() > >> # File > >> "C:\dev\projects\Main\TnT\Tools\sdk\python\Lib\site-packages\mrv\maya\nt\__init__.py", > >> line 223, in __init__ > >> # self.plugin_registry_changed() > >> # File > >> "C:\dev\projects\Main\TnT\Tools\sdk\python\Lib\site-packages\mrv\maya\nt\__init__.py", > >> line 237, in plugin_registry_changed > >> # self.plugin_loaded(pn) > >> # File > >> "C:\dev\projects\Main\TnT\Tools\sdk\python\Lib\site-packages\mrv\maya\nt\__init__.py", > >> line 297, in plugin_loaded > >> # typ._addCustomType( nt, parentclsname, tnc, force_creation=True ) > >> # File > >> "C:\dev\projects\Main\TnT\Tools\sdk\python\Lib\site-packages\mrv\maya\nt\typ.py", > >> line 428, in _addCustomType > >> # mrvmaya.initWrappers( targetmoduledict, [ newclsname ], metaclass, > >> **kwargs ) > >> # File "C:\dev\projects\Main\TnT\Tools\sdk\python\mrv\maya\__init__.py", > >> line 184, in initWrappers > >> # File > >> "C:\dev\projects\Main\TnT\Tools\sdk\python\Lib\site-packages\mrv\maya\util.py", > >> line 286, in createCls > >> # self._createdClass = self.classcreator( self.clsname, tuple(), {} ) > >> # File > >> "C:\dev\projects\Main\TnT\Tools\sdk\python\Lib\site-packages\mrv\maya\nt\typ.py", > >> line 317, in __new__ > >> # nameToTreeFunc = func_nameToTree ) > >> # File > >> "C:\dev\projects\Main\TnT\Tools\sdk\python\Lib\site-packages\mrv\maya\util.py", > >> line 326, in __new__ > >> # parentcls = module.__dict__[ parentclsname ] > >> # KeyError: ('UnknownPluginManipContainer',) # > > >> thanks, > >> -Judah > > >> On Wed, Apr 7, 2010 at 7:15 AM, Sebastian Thiel <[email protected]> > >> wrote: > > >> > MRV is an open-source multi-platform python development environment to > >> > ease rapid development of maintainable, reliable and high-performance > >> > code to be used in and around Autodesk Maya. > > >> > MRV adds a lightweight convenience layer on top of the Maya API > >> > exposed to python, correcting inconveniences and sources for common > >> > programming errors on the way. It essentially enables a more efficient > >> > way of using the Maya API by allowing more intuitive access to maya's > >> > nodes, the DAG and the dependency graph. In effect, it greatly > >> > improves the programmers productivity. > > >> > As programming convenience within python is achieved at runtime, it > >> > clearly comes at the cost of performance, which is why MRV will always > >> > allow you to operate directly on MayaAPI objects, bypassing the > >> > convenience wrapper to optimize tight loops or performance critical > >> > sections if needed. > > >> > As an additional benefit, it provides an extensible undo system to > >> > enable undo for the most common wrapped API operations, hence programs > >> > requiring user interaction will work natively within maya at no > >> > additional development costs, undo usually does not need to be > >> > implemented explicitly. If no undo is required, MRV can automatically > >> > use alternative implementations which incur no undo overhead at all to > >> > additionally boost performance in non-gui modes of operation. > > >> > MRV is versatile, as it runs on all platforms supported by Maya, > >> > starting at Maya 8.5 up to the latest version. Using MRV it is easy to > >> > write standalone applications, using a standalone python interpreter > >> > as long as access to the maya python libraries is available. > > >> > MRV is extensible, allowing you to add convenient interfaces to your > >> > plug-in nodes without any boilerplate code. You can configure and > >> > define every aspect to your liking or your specific needs, making it > >> > especially useful for 3D-production pipeline development. > > >> > Reliability is a major concern, hence everything within MRV is backed > >> > up by unittests. New features are implemented using test-driven > >> > development practices , new releases are only done if no unittest > >> > fails on any supported platform. > > >> > If you want to learn more, please have a look at the online > >> > documentation at > > >> >http://packages.python.org/MRV/index.html > > >> > Kind Regards, > >> > Sebastian > > >> > -- > >> >http://groups.google.com/group/python_inside_maya > > >> > To unsubscribe, reply using "remove me" as the subject. > > >> --http://groups.google.com/group/python_inside_maya > > > -- > >http://groups.google.com/group/python_inside_maya > > --http://groups.google.com/group/python_inside_maya -- http://groups.google.com/group/python_inside_maya
