Update Nuke stubs to reflect API additions in 16.0+

[nrusch]

This is a placeholder issue to get the stubs updated for Nuke 16, including checking for coverage of new Python APIs.

[chadrik]

Eden mentioned this to me the other day. I don’t have a personal license of Nuke, so we should setup GitLab sync for this repo so we can generate inside the studio.

…

On Fri, May 9, 2025 at 2:43 PM Nathan Rusch ***@***.***> wrote: *nrusch* created an issue (LumaPictures/cg-stubs#20) <#20> This is a placeholder issue to get the stubs updated for Nuke 16, including checking for coverage of new Python APIs. — Reply to this email directly, view it on GitHub <#20>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAPOE26JPZ2AU3FL7VIET325UOQZAVCNFSM6AAAAAB42AHSFOVHI2DSMVQWIX3LMV43ASLTON2WKOZTGA2TGMRVGY2TSNI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[nrusch]

I've been working on getting a local Docker environment up to try and iterate on this. I have a couple of Nuke licenses, but they're login-based, so I'm waiting to hear back from Foundry with some info on getting them working in a headless environment.

[JasonGilholme]

@nrusch If 'login-based' and 'node-locked' are at all synonymous then it might be worth looking into setting the MAC Address of the container as part of the entrypoint script. This is what we do for running RLM servers hosted in Kubernetes.

They may very well be two different things, but thought it might prove helpful. 👍

[nrusch]

Hey Jase! Unfortunately they are not the same thing. That's an interesting idea though... it's possible that the login license tokens are also tied to the system's MAC address. Still waiting to hear back from Foundry on possibilities.