fpt-publish

Publishing to ShotGrid Toolkit

Applies to any Toolkit-configured project and publish type, not one spot's comp delivery. Everything here was falsified in-vivo; none of it is inferable from the template definitions.

For template tokens, PublishedFileType lists and the PublishedFile vs Version distinction use search_sg_docs — that is the reference layer. This skill is the order of operations and what fails silently.

The two silent failures

1. {name} derives from the Step — it is never invented

The {name} token in a publish template resolves from the pipeline Step (LGT, ANM, CMP), not from a literal you choose. Writing a plausible word there produces a path that resolves, publishes without error, and lands somewhere no loader looks for it.

When the user says "put light in the name", that is the convention being requested, not a string literal.

Corollary, confirmed in-vivo: {name} rejects underscores. A filter_by on the token silently refuses my_name-shaped values. If templates behave as though your edit never happened, reload them (tk.reload_templates()) before suspecting anything else.

2. Resolve before you publish

Call tk_resolve_path and read the path it returns before tk_publish. It answers from the project's real PipelineConfiguration, so it is the only statement about where the file is going that is not a guess.

Publishing first and inspecting after means the copy has already happened.

Image sequences (%04d / ####)

tk_publish takes a sequence path as ONE publish with the frame token left in place — never one publish per frame. Existence means at least one frame on disk; a pattern that matches nothing is refused, as is mixing a sequence with a single-file path.

• Register a render in place (it already sits at its final path): pass the %04d path as publish_path and no local_path. Nothing is copied.
• Copy into the pipeline: pass the %04d render as local_path. With a PipelineConfiguration, a template carrying {SEQ} resolves to a %04d path and every frame is copied keeping its number. When the version lives in a folder (…/v003/…), the next version is read from the version folders.
• The response carries frames: {count, first, last} — relay it; a count lower than the rendered range means frames are missing on disk.