Add missing setConfigIOProxy call to the Python API

[remia]

No description provided.

[cedrik-fuoco-adsk]

Looks good to me, thanks @remia !

[zachlewis]

LGTM!

Your tests confirm what I've found for myself in the past... that there's a lot of cache-resetting involved to get things to behave correctly.

[remia]

LGTM!

Your tests confirm what I've found for myself in the past... that there's a lot of cache-resetting involved to get things to behave correctly.

Yeah I struggled a bit at the beginning when trying to use this feature! One thing I haven't been able to get working in practical way for now is patching LUTs files that rely on environment variable for their path / name (which is to be expected as it wasn't part of the initial requirements for archiving IIRC), that may be a future investigation.

[doug-walker]

Thanks for adding this Remi. I have two comments, though they could be done in a follow-up.

1. Perhaps it would make sense to have setConfigIOProxy clear the file and processor caches? (I don't consider it a bug that this is required, but given that it is required, it seems safer to have the function do it.)
2. Perhaps it would be helpful to add some additional info to OpenColorIO.h to explain the difference between CreateFromConfigIOProxy and setConfigIOProxy? (The current info on setConfigIOProxy is a bit misleading since it says it could provision the config.) And the Context one could be updated to refer to the Config one. Here is the info Cedrik provided on Slack:

The ConfigIOProxy class provides two methods, getLutData and getConfigData, which can be overridden in a custom class that inherits from ConfigIOProxy. These methods enable the retrieval of LUT data/files and configuration data, respectively, from a customised location.

When Config::setConfigIOProxy() is called to set a custom implementation of ConfigIOProxy, the getLutData method from the custom class will be invoked when OpenColorIO attempts to locate LUTs in FileTransforms, rather than relying on the file system.

When Config::CreateFromConfigIOProxy() is called, a custom implementation of ConfigIOProxy is passed, but not stored within the Config object, unlike Config::setConfigIOProxy(). In this scenario, the custom implementation of getConfigData will be called to retrieve the configuration data.

[doug-walker]

One thing I haven't been able to get working in practical way for now is patching LUTs files that rely on environment variable for their path

I'm suprised that doesn't work. The archive feature does support context variables in the search_path as long as they are relative to the working directory.

[remia]

Agreed with your points above @doug-walker, I would vote to take care of this for OCIO 2.5 and we should create an issue for that.

Regarding the ConfigIOProxy and Context variables, I need to remind myself exactly what was the issue, from vague memory it was not in the ConfigIOProxy directly but more in how it interacts with the context and file location resolution in my specific use case. I'll create an issue for it if needed when I get time.

[doug-walker]

I created issue #2130 to capture the remaining work and will go ahead and merge this for OCIO 2.4.2.

[remia]

I created issue #2130 to capture the remaining work and will go ahead and merge this for OCIO 2.4.2.

Thank you @doug-walker !