Pyblish and Shotgun's publish2

[marcus]

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

• Documentation

Overview

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

Screenshots

Main View	Layout	Logging View

Order

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

tk-multi-publish2.yml

settings-tk-multi-publish2.maya.shot_step:
  collector: "{self}/collector.py:{engine}/tk-multi-publish2/basic/collector.py"
    Work Template: maya_shot_work
  publish_plugins:
    - name: Publish to Shotgun
      hook: "{self}/publish_file.py"
      settings: {}
    - name: Upload for review
      hook: "{self}/upload_version.py"
      settings: {}
    - name: Begin file versioning
      hook: "{engine}/tk-multi-publish2/basic/start_version_control.py"
      settings: {}
help_url: *help_ur
location: "@apps.tk-multi-publish2.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.

/publish2demo2/config/env/includes/settings

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(...):
  pass

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(...):

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

Summary

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.