[Build] Integrate OpenAssetIO

[elliotcmorris]

Closes #15

Add OpenAssetIO as a dependency of the resolver, so that OpenAssetIO methods can be use to implement resolver interface methods.

Add OpenAssetIO building to the test automation along with this. We use the OpenAssetIIO docker container to make getting dependencies for the build easier, and then move the build made inside that container between jobs, (helpfully, our container and the vfxall container are the same base, intentionally, so this is compatible.)

Doing this also means we end up writing an openassetio logger interface implementation, which while it's tested insofar as we know it logs things, it could be tested more thoroughly. However, OpenAssetIO currently only sets severity upon construction, which is problematic to test when it's puppeted by something else.

[foundrytom]

However, OpenAssetIO currently only sets severity upon construction, which is problematic to test when it's puppeted by something else.

You should be able to set the severity any time you like https://github.com/OpenAssetIO/OpenAssetIO/blob/fbc24bbeb32f6aa0c43cc985310364fa3816bc30/src/openassetio-core/include/openassetio/log/SeverityFilter.hpp#L53

[feltech]

However, OpenAssetIO currently only sets severity upon construction, which is problematic to test when it's puppeted by something else.

You should be able to set the severity any time you like https://github.com/OpenAssetIO/OpenAssetIO/blob/fbc24bbeb32f6aa0c43cc985310364fa3816bc30/src/openassetio-core/include/openassetio/log/SeverityFilter.hpp#L53

This was more about using the environment variable to be able to control the severity from the (Python) USD application, which has no access to the OpenAssetIO SeverityFilter instance.

The severity is initialised by the env var only on construction of the SeverityFilter, after which the env var isn't read again. We did wonder, in passing, if that was a wise design, given e.g. a debug workflow of enabling debug severity just around a specific call, to avoid noise polluting the log output.

[foundrytom]

The severity is initialised by the env var only on construction of the SeverityFilter, after which the env var isn't read again. We did wonder, in passing, if that was a wise design, given e.g. a debug workflow of enabling debug severity just around a specific call, to avoid noise polluting the log output.

Do you mean in general, or in this instance? More generally, it is the host that decides how logging should be filtered vs OpenAssetIO - SeverityFilter is just a convenience class that provides a default mechanism for simple hosts that dont want to have to think about it too much. I dont think we have an expectation that it is always used. If a host supports run-time logging severity changes, then we'd encourage them to implement a logger interface that is coupled to those in a way that makes sense to the user.

[feltech]

The severity is initialised by the env var only on construction of the SeverityFilter, after which the env var isn't read again. We did wonder, in passing, if that was a wise design, given e.g. a debug workflow of enabling debug severity just around a specific call, to avoid noise polluting the log output.

Do you mean in general, or in this instance? More generally, it is the host that decides how logging should be filtered vs OpenAssetIO - SeverityFilter is just a convenience class that provides a default mechanism for simple hosts that dont want to have to think about it too much. I dont think we have an expectation that it is always used. If a host supports run-time logging severity changes, then we'd encourage them to implement a logger interface that is coupled to those in a way that makes sense to the user.

That's a good point. It is really just an issue in this instance (and I guess similar situations), where the outer application has no direct visibility or control over the OpenAssetIO host functions. Probably a rare case, and if we become really bothered by it, like you say, we could write something similar to SeverityFilter but customised just for this project's use cases.