Custom IODescriptor Types for tk-core

Pipeline Integrations
,
1

Hello,

I would like to have the ability to define custom IODescriptor types via a hook or some other method.

I have started some work on this here: https://github.com/shotgunsoftware/tk-core/pull/768

However @jfboismenu has shown some of the issues with my currently incomplete implementation.

It was recommended to me that I reach out to the community to determine interest before I go down this route any further.

My current implementation allows for customized IODescriptor types, and will load your custom hook on the creation of the first IODescriptor

So yeah, this is a starting place to gauge interest in this feature. To see if it’s just me looking for this level of customization.

Thanks
-Alex

3

Hi Alex!

Did this gain any traction with the Toolkit development team? We’ve had to for tk-core at our own studio as well to add a custom IODescriptor, and are hoping to not take on the technical debt of maintaining a fork.

Thanks!
Nikhil

4

I’m also interested in this potential feature!

5

Although the existing IODESCRIPTOR mechanism isn’t really designed for custom types without violating loading and caching assumptions, this tk-core functionality is undoubtedly necessary.

Hooks are a fantastic concept, but lifecycle problems quickly cause chaos, which is why most studios choose to fork rather than extend.

If it does occur, tk-core becomes unstable and requires a suitable registry/factory design rather than loose runtime hooks.

6

Fair point about the registry pattern being cleaner architecturally, but here’s the thing — that’s also a bigger change to get approved and merged, which is probably why everyone just forks in the first place. The design argument tends to stall out while studios need the feature yesterday. Not saying Alex’s hook approach is perfect, but I wonder if the real blocker is just getting the core team to prioritize this at all, whether it’s hooks or factories.