move import of ufeSelectCmd inside selectPath() function in ufeUtils #1237
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Attempting to import
ufeSelectCmd
beforemaya.standalone.initialize()
has been called will raise anImportError
and cause tests to fail. For example, this would be the case for test cases that are decorated with theunittest.skipUnless()
decorator and useufeUtils.ufeFeatureSetVersion()
, since the decorator will be executed beforesetUpClass
has a chance to run and initializemaya.standalone
.This change addresses that by pushing the import of
ufeSelectCmd
into theselectPath()
function where it is used rather than having it at the top of the file. This ensures that theufeUtils
module can be imported andufeUtils.ufeFeatureSetVersion()
can be called safely beforemaya.standalone.initialize()
.Note that this does not currently manifest as an issue when running the unit tests using the CMake infrastructure in this repo since we inject the Maya standalone initialization early in every test:
maya-usd/cmake/test.cmake
Line 154 in d1fe7cd
We do not do that in our internal test infrastructure, which is why this is problematic for us. Ultimately, it seems like it would be preferable not do to that in CMake either and make sure that every test script can run successfully on its own without requiring additional patching from the test harness. There are likely other changes along the lines of this one needed to make that a reality, but this is hopefully one more small step in that direction.