SG-43811 migrate flow write node by yungsiow · Pull Request #135 · shotgunsoftware/tk-nuke

yungsiow · 2026-06-29T16:41:07Z

Summary: Port the FlowWrite node implementation in Nuke of POC to Nuke engine, and adapt the user flow more in line with existing SG Write node.

Details:

Added FlowWriteNode class to Nuke engine
Kept original create and pre-render callbacks attached to node to ensure node is created under the right conditions, and renders go to the right place
Removed the post-render callback that published renders to Flow - this will be handled via the Publisher app from now on
Ensured the Nuke collector detects FlowWrite node renders and types them correctly, storing pertinent information in publish item about the FlowWrite renders
Add a publish script for FlowWrite nodes specifically which will do some post processing on the node after the publish is complete
During NukeHost initialization, register the FlowWrite node in the tab menu of Nuke and hook up callbacks

- added .flake8 config copied from tk-core - added vim lock files to .gitignore - implemented NukeHost subclass of FlowHost NOTE: FlowWrite node will be ported in a separate ticket - instantiate NukeHost during engine set up

- add custom FlowWriteNode class to flowam module - collect renders of FlowWriteNodes in publisher - post-publish add asset id back to FlowWrite node and save file

codecov · 2026-06-29T16:45:15Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 19.89%. Comparing base (a87de68) to head (43e3161).

Additional details and impacted files

@@                        Coverage Diff                         @@
##           ticket/sg-43461/migrate-nuke-host     #135   +/-   ##
==================================================================
  Coverage                              19.89%   19.89%           
==================================================================
  Files                                      6        6           
  Lines                                    553      553           
==================================================================
  Hits                                     110      110           
  Misses                                   443      443

Flag	Coverage Δ
Linux	`18.80% <ø> (ø)`
Python-3.10	`19.89% <ø> (ø)`
Python-3.11	`19.89% <ø> (ø)`
Python-3.13	`19.89% <ø> (ø)`
Python-3.9	`19.89% <ø> (ø)`
Windows	`18.80% <ø> (ø)`
macOS	`17.90% <ø> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

…/migrate-flow-write-node

- line endings on flow_write_node.py - remove top level imports of flow modules

chenm1adsk

Left some questions :)

chenm1adsk · 2026-06-29T19:11:21Z

+HookBaseClass = sgtk.get_hook_baseclass()
+
+
+class NukeFlowWritePublishPlugin(HookBaseClass):


Sorry I am not quite understand nuke hooks here. I am wondering why we need two different publish hooks? Are they get triggered differently?

Yes, and my understanding is also not great. The original one only deals with Nuke "session" publishes - i.e. nuke script files. The item filter only accepts these. And since I need specific publish behaviour for the renders (which is different than scripts) - specifically a bit of post processing - the way to ensure I can "catch" those publishes is by creating a custom publisher which does the normal generic publish, but then some extra functionality after. Hope that makes sense!

Thanks for the explanation. I am thinking should we move nuke_flow_write_publish_script.py inside nuke_publish_script.py and use context to check if we trigger flowam logic for nuke script publish workflow?
In this case, user don't need to update their config to add a new hook to be able to use flowam logic (same as collector.py/pre_publish.py/publish_file.py in native tk-multi-publsih2).
What do you think?

chenm1adsk · 2026-06-29T19:26:29Z

+        )
+
+        self.logger.info("Registering global callbacks for Write nodes...")
+        nuke.addKnobChanged(FlowWriteNode._on_update_flow_write, nodeClass="Write")


Do we need to remove registered callback on tear down? Would this registered callback accumulate?

Yes this is a good idea. I haven't been doing that in the host code and probably should. Let me look into that!

chenm1adsk · 2026-06-29T19:28:06Z

+
+        # Check for mandatory properties
+        if not write_node["asset_name"].value().strip():
+            nuke.message("Asset Name must be set.")


I am wondering why we need two messages here. Does nuke.message display differently?

Yes I think Nuke.message() pops up a little dialog.

carlos-villavicencio-adsk

I believe the code style validation check if failing.

carlos-villavicencio-adsk · 2026-06-30T22:22:08Z

+This modules contains the callbacks that support our specific Flow integration.
+"""
+
+from __future__ import annotations  # needed for python 3.9 support


Since this code is not going to run on Houdini (because this is Nuke engine) probably we don't need this. Not sure if I'm missing something.

Is it the case that we don't support any Nuke engines that run python 3.9? I just never know when we need this and when we don't!

Yes, Nuke 15 is the min version supported and it comes with Python 3.10.

carlos-villavicencio-adsk · 2026-06-30T22:22:47Z

+    from .flow_write_node import FlowWriteNode
+
+    # Ensure flow host exists
+    host = sgtk.platform.current_engine().flow_host


Do we want to do a core check here as well?

chenm1adsk

LGTM!

carlos-villavicencio-adsk · 2026-07-03T21:21:29Z


+    def _in_flow_context(self) -> bool:
+        """Return True if in a Flow-enabled context."""
+        return hasattr(self.parent.engine.context, "flow_project_id")


Suggested change

return hasattr(self.parent.engine.context, "flow_project_id")

return getattr(self.parent.engine.context, "flow_project_id", None) is not None

yungsiow added 7 commits June 22, 2026 13:09

Nuke flow host support

c4d4f45

- added .flake8 config copied from tk-core - added vim lock files to .gitignore - implemented NukeHost subclass of FlowHost NOTE: FlowWrite node will be ported in a separate ticket - instantiate NukeHost during engine set up

Add comment

273d973

Update .gitignore

98bc99a

Remove import alias

6d89dd9

Addressed PR comments.

09b307c

Migrate FlowWrite custom node

19b3079

- add custom FlowWriteNode class to flowam module - collect renders of FlowWriteNodes in publisher - post-publish add asset id back to FlowWrite node and save file

support movie types and single images

2f92051

yungsiow added 3 commits June 29, 2026 14:42

Fix backwards compatibility with old tk-core

a87de68

Merge branch 'ticket/sg-43461/migrate-nuke-host' into ticket/sg-43811…

b3fc347

…/migrate-flow-write-node

ensure backwards compatibility with old tk-core

7ad0ba9

- line endings on flow_write_node.py - remove top level imports of flow modules

chenm1adsk reviewed Jun 29, 2026

View reviewed changes

Unregister callbacks when NukeHost instance is destroyed

43e3161

carlos-villavicencio-adsk reviewed Jun 30, 2026

View reviewed changes

Base automatically changed from ticket/sg-43461/migrate-nuke-host to master July 2, 2026 21:22

chenm1adsk approved these changes Jul 3, 2026

View reviewed changes

carlos-villavicencio-adsk reviewed Jul 3, 2026

View reviewed changes

		HookBaseClass = sgtk.get_hook_baseclass()


		class NukeFlowWritePublishPlugin(HookBaseClass):

	return hasattr(self.parent.engine.context, "flow_project_id")
	return getattr(self.parent.engine.context, "flow_project_id", None) is not None

Uh oh!

Conversation

yungsiow commented Jun 29, 2026

Uh oh!

codecov Bot commented Jun 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

chenm1adsk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

carlos-villavicencio-adsk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chenm1adsk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

codecov Bot commented Jun 29, 2026 •

edited

Loading