Shotgun extension

Pyblish Development
#9

I think the main point is to give the option of using Shotguns publishing UI and Pyblishs UI. As for similarities in the interface we might be able to do something, but it may not be worth it. Think the main point is giving developer access to version control.

All extension are python packages, so it might be a good idea to keep all functional code in pyblish-shotgun, so you can do something similar to this in the primary_pre_publish:

import pyblish_shotgun

class PrimaryPrePublishHook(Hook):

    # initialization code ...
    # check if pre_publish is in Maya, if Maya call self._do_maya_pre_publish() method

    def _do_maya_pre_publish(self, task, work_template, progress_cb):
    
        progress_cb(0.0, "Validating current scene", task)

        if scene_file:
            scene_file = os.path.abspath(scene_file)
        
        # validate it:
        scene_errors = pyblish_shotgun.validate_all()
       
        progress_cb(100)
      
        return scene_errors
#10

That’s exactly what I had in mind. So the user doesn’t even know (or need to know) we are using different internals

Shotgun do have a framework model for shared code. However it is quiet specific to Shotgun so code sharing between different Production Tracking systems is not possible.

So I guess another way to approach it is to use pyblish-shotgun as a library that can be used either by Shotgun Publish hooks or a very thin Shotgun App that really is just a launcher that launch a instance of Pyblish GUI.

#11

I would say that if a user wants to use more of a standard Pyblish workflow, just let them use the filemenus in the different hosts.

#12

@tokejepsen, do you still have that video of an ftrack Action launching Pyblish? Maybe that would be similar to how Shotgun Apps are launched?

#13

This directly launched Pyblish from Ftrack in the browser. Is this similar to what you mean @dshlai? Guessing it’ll be launched from Shotgun desktop.

#14

Shotgun in Maya is like this:

#15

This is call Action Menu in Shotgun Web UI

Pasted image380×553 27.5 KB

#16

Most artists publish their work file in the host app, not from the Web UI.

#17

And you were thinking that you’ll have another entry called Pyblish UI... underneath the Shotgun filemenu?

Right now I think its just cosmetics:) You can decide where to put the access to the Pyblish UI. Main point is to have the library of pyblish related code in pyblish-shotgun.

One thing to look out for would be that the pyblish-maya extension, automatic creates a Publish entry underneath File in Maya. This may confuse the users when they are used to go to Shotgun/Publish...

#18

Yeah, that’s where I want to put it (in the Shotgun menu).

I haven’t install pyblish-maya extension yet. In this case I will probably opt not to install that at the same time. I will like to exam that repo as well to see it work under the hood.

#19

If you aren’t going to be using Pyblish QML, then the integration isn’t going to do much for you.

The only thing of interest that I can think of are the plug-ins; the idea is for plug-ins of every host to have access to some basic facilities, such as getting the path to the currently open file through context.data["currentFile"]. That way you can bridge plug-ins by not relying on host-only libraries for that information. The more of that we have, the more flexible plug-ins can get in terms of where they run.

If you have a look at the plug-ins available for Maya (there aren’t many) and either copy those or implement your own, then your plug-ins should align perfectly with other integration packages.

#20

I can provided my own integration if necessary. I am looking at the existing repo to see how the API and convention work.

#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.