Pyblish and Shotgun's publish2

Roy discovered some similarities with Pyblish in this video from Shotgun. Some interesting bits to learn and possibly improve from.


publish2 is the name of Shotgun’s publisher. It shares a few ideas with Pyblish, like Collection, Validation and Integration but have a few interesting differences that I wanted to capture and discuss.

Difference pyblish publish2
Plug-ins One per file -||-
Output Called instance Called item
CVEI Collect, Validate, Extract, Integrate Collect, Accept, Validate, Publish, Finalize
Order Dynamically arranges the order in which plug-ins are called Statically declares an order in an external .yml file.
Log Terminal is where each plug-in emits debug text Called Logging View, and they’ve got a Copy to Clipboard which is very handy!
Dependencies Pyblish runs in any host accessible with Python 2.7-3.7 with QML Presumably requires PySide2 from within the host, similar to Pyblish Lite
Icons Not implemented Each item can have an icon, indicating what it is like a playblast or Maya scene file.
Commandline Implemented On the roadmap
Standalone Implemented -||-
Messages Printed at the bottom of each UI -||-
Families Determines which plug-ins to run, relative what’s in the scene Called type
UI Layout Two-columns, one for instances the other for plug-ins Hierarchical, plug-ins parented under each item
UI Comment Overlay, toggled Sidepanel, persistent
UI Dragndrop Not implemented Include ad-hoc external files in any publish
UI Thumbnail Not implemented In addition to a comment, also add an image



Here’s how you arrange which plug-ins to run and in which order.


  collector: "{self}/{engine}/tk-multi-publish2/basic/"
    Work Template: maya_shot_work
    - name: Publish to Shotgun
      hook: "{self}/"
      settings: {}
    - name: Upload for review
      hook: "{self}/"
      settings: {}
    - name: Begin file versioning
      hook: "{engine}/tk-multi-publish2/basic/"
      settings: {}
help_url: *help_ur
location: ""

A few interesting tidbits.

  1. collector Presumably not a plug-in like the others
  2. Work Template Unclear of what this is, but presumably something you can access from within a plug-in to make decisions, e.g. whether you’re publishing from Animation or Modeling.
  3. hook Presumably what’s called plugin elsewhere, and is the actual plug-in file. Possibly it’s plugin + metadata, like name and “settings”
  4. settings Presumably things that can be accessed from within a plug-in to make decisions
  5. help_url Unclear whether this applies to all plug-ins somehow, or whether it’s a meta-level help url for general help about this particular YML setup.

It’s unclear whether you define this once for all of your Shotgun integration, or per shot. The one above appears to reside in an internal Shotgun directory.


Hierarchical Items

Unlike Pyblish, publish2 can visually nest items, where plug-ins are further nested under each item.


Presumably these are evaluated from inside-out, such that the parent is published after its children, like a sort of dependency chain. Pyblish can nest and perform logic on nested instances, but it isn’t visible in the UIs.

Plug-in Help Text

Plug-ins in publish2, like Pyblish, are individual classes.

class ValidateSomething(...):

In Pyblish, the doc-string is used as help-text for both programmer and artist.

class ValidateSomething(...):
  """This validates someting"""

In publish2 the same is true, but implemented as a @property

class ValidateSomething(...):

  def description(self):
      return "This validates something"


In interesting take, for sure. Would be interesting to hear from the developers about tradeoffs made relative Pyblish more dynamic nature. The idea of declaring plug-ins from a single location is something that’s been requested for Pyblish as well; having plug-ins appear and disappear dynamically can be both a blessing and a curse, and it would be interesting to explore a similar method as an alternative for working with Pyblish.

Visually, I like the idea of having a properties page on the side. Ours is hidden within a tab which makes it a little more scary. We’re saving space, and make the UI fit for a vertical screen like a phone, but what for? We could definitely use some more horizontal space.