In preparation for upcoming extensions and integrations, I’m putting together some reference material here.
Let’s have a chat about what’s missing from here, and we’ll build upon it as we go. The goal is for each extension to follow an identical pattern, and the currently available ones may be used as reference.
That looks clear to me. Maybe adding some information about how should the setup.py file look like and where to put libraries shared across the plugins
pyblish-<extension>
├── README
├── setup.py
├── pyblish_<extension>
│ ├── plugins
│ │ └── <plugin>.py
│ ├──__init__.py
| └── optional_extension_lib.py (?)
└── tests
├── __init__.py
└── <test>.py
I think it would be great if Writing Integrations could get some more in-depth information, like on how to actually go about implementing the connection with the host. Maybe take 3 integrations as an example and how they differ. This also quickly lets people know what they are looking for in a host and what references they have in regards of other integrations.
So information like this:
The core ingredients for a Pyblish integration are:
threading.Thread
To test whether 1 works, you can run this:
import threading
def worker():
for x in range(5):
time.sleep(1)
print "Sleeping.. %i" % x
print "Done"
thread = threading.Thread(target=worker)
thread.daemon = True
thread.start()
If that prints 0 to 4 in order it works as expected.
Good idea.
I was hesitant about getting too deep into setup.py, as setup.py is only relevant for pip and easy_install, which we won’t be using.
Still considering what would be a better approach to this. Me and @tokejepsen were having a discussion about this in relation to distribution and sharing in this GitHub Issue which has a forum thread here.
Ah, yes. Very good point. That definitely belongs there.
If we’re not using it, aybe it shouldn’t be there at all in the extensions.It’s a bit confusing then. Once the distribution system you’re discussing in those links is in place. setup.py would be obsolete anyways.
I’ve also been considering the benefits of a pyblish-integration package.
Currently, integrations are nearly identical, with the primary difference being how Pyblish is added to the GUI and minor host-dependent utility functions like maintaining selection during extraction.
Initially, I expected there to be a bulk of work involved in getting Pyblish to run commands in a host, but so far almost all hosts have provided an almost identical wrapper that solved all problems - i.e. executeInMainThreadWithResult.
An integration package could work along the lines of this.
# Maya integration psuedo
import maya.util
import pyblish_integration
pyblish_integration.register_threaded_wrapper(
maya.util.executeInMainThreadWithResult)
def gui_callback():
"""Append Publish to file-menu"""
maya.cmds.menu("Publish")
pyblish_integration.register_gui_callback(gui_callback)
…in cases where a wrapper isn’t enough. The Modo integration is an example of this, and looks like Fusion is too.
Still, perhaps it could provide what is common, whilst still allowing for bespoke integrations to take place. It may even be possible, or even likely, that whatever it takes to get Fusion integrated is the exact same procedure as for Modo and possibly other hosts as well.
You are probably right. They exist for legacy reasons, as Pyblish used to be (and still can be, actually) fully installed via pip. But it isn’t a lasting solution, as we’ve covered already.
I like this a lot. It might also result in more consistent behavior (meaning we shouldn’t run into issues if one integration is behind the others) considering all integration would be using the same pyblish_integration package.
Yes, and not to mention the simplified maintenance efforts. Currently, a change to the Pyblish Endpoint/QML interface means updating every integration. :S
If you find the time @mkolar, you are welcome to have a go with this. I’ve got my hands full with DI and seeing as we’re getting more and more integrations lately, this is getting increasingly important.