Issues porting custom plugin from 7.2 to 8.0.10.4

Deadline
1

I’m trying to port a custom plugin from 7.2 to 8.0, and I’m running into a few issues.

First, the plugin lives outside of the Deadline repo, and for every job submission, I pass a customPluginDirectory JobInfo key that points to the directory containing the named plugin directory. This has been working fine for years with Deadline 6 and 7, but now when trying to submit a job (via the REST API), I constantly get:

Error: plugin name specified by job, "LumaJob", is not a known plugin name.

If I copy the LumaJob plugin directory into the repository’s ‘custom/plugins’ subdirectory, I am able to submit a job using the plugin, but I would like to continue using an external definition.

Second, it seems that MultiLineString controls don’t work the same way as they did in 7.2, or they’re just broken in 8.0, but it’s not clear why. This custom plugin has two MultiLineString controls defined in its .options file. Once I had a job submitted using my plugin (while it was living in the repository), I opened the Job Properties dialog, and when I went to the “LumaJob Settings” section, I got two tracebacks in the Monitor console, and neither of the MultiLineString widgets showed up (only their labels). The errors look like:

Traceback (most recent call last): File "DeadlineUI/Forms/JobOptionsForm.py", line 392, in addNewWidget TypeError: __init__() takes at most 3 arguments (4 given)

My control definitions basically look like this:

[configData] Type=MultiLineString Label=Job Config Data Description=Specific config data used by this job Category=Dev Index=1 Required=True Default=

None of the shipped application plugins use the MultiLineString control, so I have nothing to reference for changes except the documentation, which makes it sound like this should continue to work as expected.

Thanks for any help here.

2

Also, if I get a job submitted by copying the plugin folder into the repository’s custom/plugins directory, and then remove it once the job is on the farm, the job will fail repeatedly with:

Failed after four attempts to copy "LumaJob.param". Please make sure that the file exists in the plugin directory.

So it doesn’t look like Deadline is even trying to use the custom plugin directory defined on the job.

3

I’ll log that first and the last ones in as bugs. Seems easy enough.

For multi-line boxes, they shouldn’t have changed. I just used the folder equivalent yesterday:

[CleanupPaths]
Type=MultiLineMultiFolder
Category=Cleanup Options
CategoryOrder=1
CategoryIndex=0
Label=Cleanup Paths
Default=
Description=One or more directory paths (local or network) which the slave will attempt to recursively scan and delete files/dirs (absolute file path only, relative not supported).

github.com/ThinkboxSoftware/Dea … p.param#L8

Feel free to e-mail that one to me off-forum and I’ll plug it in over here. I haven’t seen that regression over here.

4

OK, so the official party line is that custom plugin directories are broken in 8.0? That seems like something that should be caught during development with some basic testing…

That’s an event plugin, not a job plugin, and apparently the UIs don’t share code. I can see that the MultiLineString controls work in the “Configure Events” and “Configure Plugins” dialogs, but there are no out-of-the-box plugins that use them in their .options files, so I doubt anyone actually tested this same situation before release.

If I copy one of the MultiLineString control definitions from the Shotgun event’s .param file into my job class’ .options file, it causes the error as well, and doesn’t show up in the Job Properties dialog. However, if I copy the exact same control definition into my class’ .param file, the control shows up in the “Configure Plugins” dialog. This seems to point to a broken Job Properties UI, which again seems like something that should be caught before release.

5

Noted that it’s only affecting plugins. That must be why I personally haven’t seen it. You’re very right about the plugins too, none of them use it at the moment.

As Deadline grows in complexity, it’s becoming more difficult to test when changes happen (especially if those changes are done by someone new who doesn’t know how far a change may propagate into other features). We are working on finding better ways to test, so if there are any testing automation experts here, I’d love some ideas (should likely be in a different thread).

6

I would start by looking at Qt Test, since it will let you add GUI automation to a suite of unit tests.

As far as fixing this issue goes, is there any chance that the fixed UI code can be distributed to me directly (as a drop-in .pyc)? We use the multi-line string widgets pretty extensively, so I’m interested in getting this patched as quickly and painlessly as possible.

Thanks.

7

I’m not sure if Qt Test can work with PyQt can it? I’ll bounce it off of Jon.

As far as the built PYC, I’ll e-mail you the raw py file offlist. The next service pack should include this, but that won’t be due out for some time later this week.

8

Update here that we’ve got the custom plugin path fixed in 8.0. We’re also doing path mapping on those now so it’ll work cross-OS with less fiddling.

9

Yeah, it definitely does.

Good to hear. Is there another release imminent (beyond 8.0.11.1)?

10

Jon’s words were “early next week”. That could mean a lot of things, but it should definitely mean “before Thursday”.

11

Great, thanks.

12

Just checking in to see if there was any news on this.

13

Delays make me all kinds of sad. We’re waiting on an important change to the installers at this point, but it’s so close I can taste it.

That said, I’m out doing client visits next week, so if it is released next week I’ll ask Charles and/or Dwight to come in here and mention it.

14

8.0.12.4 has been released: docs.thinkboxsoftware.com/produc … notes.html