[mayaUsd] load Plug libraries when finding and loading in the registry #694
Conversation
| def setUpClass(cls): | ||
| standalone.initialize('usd') | ||
|
|
||
| # We load the pxrUsd plugin here to ensure that the usdUndoHelperCmd |
There was a problem hiding this comment.
We would like to move / add tests which can work with either plugin outside of plugins/... and into test/.... I believe both testUsdMayaAdaptor and testUsdMayaAdaptorUndoRedo fall into the above category?
There was a problem hiding this comment.
@kxl-adsk: Sounds good. I just rebased the original change as a95b062, and then migrated all of the UsdMayaAdaptor tests to test/lib/usd/translators. I moved them all since it seems like they should all stay together, and the ones that need plugins loaded will work with either pxrUsd or mayaUsdPlugin.
I had to fix one thing in fixturesUtils.py which I mentioned in #613 (comment), which is to only create aliases for the export and import commands if we're actually loading the plugin. Otherwise the tests where we're specifically trying not to load plugins would fail there. That fix is in c56253f.
kxl-adsk
added
core
This change ensures that even if a Plug plugin does not identify a Maya plugin
to be loaded in the "mayaPlugin" field, we still instruct the Plug library to
load its plugin, since doing so might be required to cause
readers/writers/adapters/etc. to register.
This became problematic after some restructuring of the maya-usd repo such that
the translator code was moved under lib/usd/translators, which though it is
still considered "core" mayaUsd, it is built as a separate component library.
Simply importing mayaUsd in Python does *not* cause that library to be loaded,
but loading the pxrUsd Maya plugin does. The prim writers and readers are still
identified in the plugInfo.json, but there is no longer a pxrUsdTranslators
plugin on the Maya side that goes with them.
This manifested as UsdMayaAdaptors not working in Python unless you
specifically loaded the pxrUsd plugin beforehand. With this change, that
shouldn't be necessary.
To verify this, the loadPlugin("pxrUsd") command was removed from the
testUsdMayaAdaptor test to make sure that the library is loaded correctly
through the registry discovery mechanism. The one gotcha here is that the
undo/redo test *does* depend on the pxrUsd plugin being loaded because the
adaptors can be used with or without undo support, and it is only available
when the plugin *is* loaded. To deal with that, the undo/redo test was just
moved into its own test script rather than trying to carefully control when the
plugin gets loaded and having to ensure that the suite of tests run in a
specific order.
(Internal change: 2088800)
…g mayaUsdPlugin If the plugin is not loaded, the mayaUSDExport and mayaUSDImport commands will not exist and AttributeErrors will be raised if we try to access them.
mattyjams
force-pushed
the
pr/load_Plug_library_when_finding_and_loading_in_registry
branch
from
465490f to
ec6780a
Compare
|
@mattyjams Thank you for trying the PF. You can for now ignore |
@kxl-adsk: Cool, thanks! Yeah, thought I'd give it a shot. :) |
mattyjams
deleted the
pr/load_Plug_library_when_finding_and_loading_in_registry
branch
This change ensures that even if a
Plugplugin does not identify a Maya plugin to be loaded in the "mayaPlugin" field, we still instruct thePluglibrary to load its plugin, since doing so might be required to cause readers/writers/adapters/etc. to register.This became problematic after some restructuring of the maya-usd repo such that the translator code was moved under
lib/usd/translators, which though it is still considered "core" mayaUsd, it is built as a separate component library. Simply importingmayaUsdin Python does not cause that library to be loaded, but loading thepxrUsdMaya plugin does. The prim writers and readers are still identified in theplugInfo.json, but there is no longer apxrUsdTranslatorsplugin on the Maya side that goes with them.This manifested as
UsdMayaAdaptorsnot working in Python unless you specifically loaded thepxrUsd(ormayaUsdPlugin) plugin beforehand. With this change, that shouldn't be necessary.To verify this, the
loadPlugin("pxrUsd")command was removed from thetestUsdMayaAdaptortest to make sure that the library is loaded correctly through the registry discovery mechanism. The one gotcha here is that the undo/redo test does depend on thepxrUsdplugin being loaded because the adaptors can be used with or without undo support, and it is only available when the plugin is loaded. To deal with that, the undo/redo test was just moved into its own test script rather than trying to carefully control when the plugin gets loaded and having to ensure that the suite of tests run in aspecific order.