Shotgun extension

Pyblish Development
#21

After some consideration I think option 3 should be the way to go.

Since Shotgun Toolkit API provide several Engine to which the app can be build upon, usually in the form of tk-multi-xxx app. If I want to build app that can be run from multiple platform (i.e., shell, Shotgun Web, Maya, Nuke), this is the way to go.

To start I think I will start with Shell Engine which is the command line interface to Shotgun Toolkit.

#22

We’ll be here if you need any help.

#23

Use Shotgun Toolkit app as thin launcher for Pyblish-QML is working:

1 Like
#24

github repo for Launcher:
https://github.com/dshlai/tk-multi-pyblish

1 Like
#25

I think the extension will be a separate package/repo in order conform to the pyblish extension development style. If I launch pyblish-qml from within the shotgun toolkit environment I should be able to pass the instance data converted from SGTK Context object) to pyblish-qml easily.

#26

Hmm, I think there is some confusion here about the role of the GUI.

Technically, the GUI isn’t running under any of the hosts, like Maya, Nuke or even FTrack. The GUI runs as an individual process (via subprocess), unbound by any other, much like how Maya itself runs.

Practically, you could launch Pyblish QML standalone, and let it run in the background. Then, a host such as Maya would connect with it when it comes time to publish. In fact this is the recommended workflow.

To get a better understanding of this workflow, I would suggest you launch Pyblish QML this way.

# From any shell
$ python -m pyblish-qml

This will launch QML, oblivious to Maya or Shotgun or what not.

And then, connect to it from a host, such as Maya, when it comes time to publish.

# In the Maya Script Editor
import pyblish_maya

# Start listening for commands coming from Pyblish QML
pyblish_maya.setup()

# Talk to Pyblish QML
pyblish_maya.show()

So, the general workflow, whether you use Maya, Ftrack, Shotgun or anything else, is to start Pyblish QML independently, preferably at start-up of the operating system, and then connect independently.

#27

Hi!

I did refer to the pyblish_standalone repo and here is how I run it from within the Shotgun app code:

pyblish_integration.setup()
# ... run inside retry loop ...
pyblish_integration.show()

The launcher itself is a Shotgun Toolkit app but it is really there just to provide context object. The Toolkit code itself does not require any dependency other then Toolkit itself.

#29

For some reason I didn’t get a notification about your reply, sorry about the delay.

Pyblish Standalone is designed to work without a host, purely within the OS, like from a directory. It launches an individual listener that can receive instructions from the GUI, Pyblish QML, in a terminal. I’m not sure it’s a good reference for your Shotgun integration.

Here’s what I think you need.

  1. Run pyblish_integration.setup() in your host, or ideally, pyblish_maya.setup() as you will otherwise have to handle threading issues on your own; that is, being able to run Maya commands from a separate thread. If you don’t do this, you’ll deadlock the host.
  2. Run pyblish_integration.show() or pyblish_maya.show().

That’s it.

In other words, showing the GUI should have little to do with Shotgun; it’s the plug-ins that need to communicate with it.

I would suggest you give Pyblish Maya a go first, gain an understanding of how it works with Pyblish QML, and then think about how you can best integrate with Shotgun.

#30

Thanks, I will try that. Yeah I think I need to understand more Pyblish work as well.

One quick question. So for Standalone does the listener process do the actual publish work while Pyblish-QML act like GUI for the user?

#31

Exactly, it’s the listener process that performs the actual publishing. Pyblish QML is simply the messenger and visualiser, it doesn’t know anything about a host or your plug-ins. It just draws them.

Here is a quick introduction to the topic, called “IPC”, with which Pyblish (the core) communicates with Pyblish QML (the gui).