Okay… try:
dict = locals()
if 'Draft' in dict:
ClientUtils.LogText( 'Draft found in locals(): %s' % dict['Draft'])
else
ClientUtils.LogText( 'Draft not found in locals()' )
Put this before the ‘import Draft’ statement.
Okay… try:
dict = locals()
if 'Draft' in dict:
ClientUtils.LogText( 'Draft found in locals(): %s' % dict['Draft'])
else
ClientUtils.LogText( 'Draft not found in locals()' )
Put this before the ‘import Draft’ statement.
Are all tests being run on the same slave? If they’re not on different slaves, I’m not sure what might be causing that…
It is possible, yeah. This is because all the scripts (plugins, event plugins, etc) are run in the same Python interpreter, which persists over the lifetime of the Deadline Slave application (or Monitor/Pulse, as the case may be). So any changes you make in the global scope will tend to ‘stick around’. This is the same reason you can potentially run into problems with old (cached) versions of imported modules.
We’re looking at splitting execution of individual plugins/event plugins into a separate (clean) process in the future, but this probably won’t be till Deadline 8, though.
Ok, that makes a lot more sense now if the environment can be persistent. I’m going to re-run the tests now on a single slave restarting between sessions. I’ll let you know the results shortly…
Thanks…
Andrew
Here is the output of two scenarios run on the same slave with slave restarts between each session. They both report that they have successfully imported Draft but only after reload does Draft.file_ report back the actual file. Without reloading it is somehow saying it is finding Draft from none…?
APPEND NO RELOAD
ConvertThumbnail:
BEFORE: Failed to find Draft
Traceback (most recent call last):
File “none”, line 130, in ConvertThumbnail
ImportError: No module named Draft
Appending ‘R:\Repository\Draft\Windows\64bit’ to Python search path
Draft not found in locals()
Importing Draft to perform Thumbnail conversion…
AFTER IMPORT - BEFORE RELOAD: Draft found in: R:\Repository\Draft\Windows\64bit\Draft.pyd
NO RELOAD
Draft found in locals(): <module ‘Draft’ from ‘none’>
Successfully imported Draft!
none
Reading in image ‘I:\PRJ\0_NIM_TEST\NIM\IMG\TST_001\COMP\TST_001_COMP_NukeTEST_v22\TST_001_COMP_NukeTEST_v22.0006.jpg’
Failed to read image
Traceback (most recent call last):
File “none”, line 212, in ConvertThumbnail
AttributeError: ‘module’ object has no attribute ‘Image’
APPEND AND RELOAD
ConvertThumbnail:
BEFORE: Failed to find Draft
Traceback (most recent call last):
File “none”, line 130, in ConvertThumbnail
ImportError: No module named Draft
Appending ‘R:\Repository\Draft\Windows\64bit’ to Python search path
Draft not found in locals()
Importing Draft to perform Thumbnail conversion…
AFTER IMPORT - BEFORE RELOAD: Draft found in: R:\Repository\Draft\Windows\64bit\Draft.pyd
RELOAD DRAFT
AFTER RELOAD: Draft found in: R:\Repository\Draft\Windows\64bit\Draft.pyd
Draft found in locals(): <module ‘Draft’ from ‘R:\Repository\Draft\Windows\64bit\Draft.pyd’>
Successfully imported Draft!
R:\Repository\Draft\Windows\64bit\Draft.pyd
I’m afraid this one has me stumped. At least a work-around is that call to reload.
What are the contents of your ‘R:\Repository\Draft\Windows\64bit’ folder?
The Python.NET import hook is the only thing I can think of that could cause this, and since the ‘import Draft’ statement seems fail outright before adding that folder to sys.path, I suspect there might be something odd in that folder (any file with the name Draft that’s not Draft.pyd would qualify as odd).
If it hasn’t been touched at all though, I’ll be really confused.
Hrm… that folder looks normal…
avcodec-54.dll
avformat-54.dll
avutil-51.dll
boost_python-2_6-vc90-mt-1_46_1.dll
boost_python-2_6-vc90-mt-1_53.dll
boost_python-2_6-vc90-mt-1_55.dll
colors.xml
Draft.pyd
DraftParamParser.py
libx264-125.dll
SourceSansPro-Regular.otf
swscale-2.dll
tbb.dll
type.xml
Version
Now… the only thing I could think of is I do have a custom event override for Draft in Repository/custom/events/Draft/Draft.py and that also runs at the same time the NIM.py event runs possibly confusing the slave???
That might be a problem, depending on the types of changes, I suppose. Could you post your custom version of the Draft event plugin?
Hmmm, there doesn’t seem to be anything in there that would cause any problems…
Based on the list of symbols present in Draft’s dict in one of your earlier posts though, I’d say it’s definitely somehow finding the Draft event plugin and importing it (either the one we ship, or your custom one, not sure which).
Can you try renaming the Draft event plugin (and all other files associated with it, obviously) to something else, like ‘DraftEvent’? Might need to do this for both your custom one and the one we ship. I still have no idea how on earth it’s finding it the first time through, I’m guessing it’s some weird thing with Python.NET’s import hook that we’ve never run into before (it does a bunch of weird stuff with implicit loading). Or might be that the current directory is somehow getting set to the Draft event folder, but that seems less likely…
Yea, it’s really odd. When I can I’ll change the event name and the calls to it and see what happens…
Thanks…
Andrew