feat: Add custom OCIO config to job attachments when enabled

[agerveshi]

What was the problem/requirement? (What/Why)

When auto-detecting job attachments, the script file from the root node and then all file knobs from the other nodes in the graph are considered. Additionally, a custom OCIO config file can be specified on the root node. When enabled, this config file and it's corresponding LUTs should also be added as job attachments.

What was the solution? (How)

When auto-detecting job attachments, determine if the script is configured to use a custom OCIO config. Load the config in to get the LUT search path. Add the config file and the LUTs directory as job attachments.

What is the impact of this change?

Users will be able to use custom OCIO configs without having to manually add the config file and LUTs directory as job attachments.

How was this change tested?

• Verified the config file and LUTs dir show up in the submitter dialog only when custom OCIO config is enabled.
• Successfully submitted a job to the farm.
• Added unit test and job bundle output test.

Did you run the "Job Bundle Output Tests"? If not, why not? If so, paste the test results here.

Yes, includes result of added test.

Timestamp: 2023-09-19T17:29:17.379558+00:00
Running job bundle output test: /home/rocky/src/deadline-cloud-for-nuke/job_bundle_output_tests/multi-load-save

multi-load-save
Test succeeded

Timestamp: 2023-09-19T17:29:17.583315+00:00
Running job bundle output test: /home/rocky/src/deadline-cloud-for-nuke/job_bundle_output_tests/noise-saver

noise-saver
Test succeeded

Timestamp: 2023-09-19T17:29:17.776855+00:00
Running job bundle output test: /home/rocky/src/deadline-cloud-for-nuke/job_bundle_output_tests/ocio

ocio
Test succeeded

Timestamp: 2023-09-19T17:29:17.986953+00:00
Running job bundle output test: /home/rocky/src/deadline-cloud-for-nuke/job_bundle_output_tests/cwd-path

cwd-path
Test succeeded

All tests passed, ran 4 total.
Timestamp: 2023-09-19T17:29:20.526923+00:00

Was this change documented?

No

Is this a breaking change?

No, this is an additive change.

[rmv]

LGTM for a first implementation, I would create a follow up ticket regarding OCIO env vars, or fix it here.

[rmv]

LGTM if this adds all directories inside the path recursively

[mwiebe]

Adding them as input directory adds the whole directory tree, yes.

[rmv]

There's one tricky thing wih OCIO which is it also uses env vars to define library settings

https://opencolorio.readthedocs.io/en/latest/guides/using_ocio/using_ocio.html

Those will override the knob settings. Maybe there's a specific Nuke call to grab the OCIO env var it's using taking env vars into account

[rmv]

Another approach is to just forward OCIO* env vars to the worker and let Nuke do its thing.

[agerveshi]

I will file an internal ticket for forwarding OCIO variables

[rmv]

Also, I think you need to squash all the commits and make the comment there follow the "conventional commits" rules (as you did for the PR title)

[mwiebe]

I see that we're providing both of these as input directories for job attachments. Does Nuke apply the path mapping to these search paths automatically, or do we have to do some special processing?

Also, do any of the LUT file formats contain further references to additional files?

[agerveshi]

I added both search paths to this config so we could test relative and absolute. In the relative case OCIO will search relative to the config file's directory. Is that what you mean by path mapping?

Good question about the LUT files, let me take a look.

[agerveshi]

LUT files do not seem to contain references to other files.

[mwiebe]

Adding them as input directory adds the whole directory tree, yes.