Hosts + Integration

This is a feature proposal to help solve the current issue of hard-coded hostnames for use in plug-ins.

Goal

Facilitate the inclusion of any host, without needing to alter surrounding libraries.

Motivation

Currently, a few hosts are supported by the core Pyblish library. They are currently hard-coded to look at an executables filename, and only a few are supported. This means that whenever a new host comes along, such as Softimage or Clarisse, the core library must be updated to include them.

Implementation

Integrations will register supported hosts at run-time, and Pyblish will be capable of supporting multiple concurrent hosts; such as maya and python.

This is the full API.

# From the Maya integration
import pyblish.api
pyblish.api.register_host("maya")

As you can see, there is no longer any need for evaluating the executable of the currently running software, instead the host is determined by it’s integration. An integration can then register multiple hosts, if needed, where it makes sense to do so, and then have plug-ins operate on individual parts of a software package.

import pyblish.api
pyblish.api.register_host("maya")
pyblish.api.register_host("mayapy")
pyblish.api.register_host("mayabatch")

For which plug-ins could support one or more of these.

class MyPlugin(...):
   hosts = ["maya", "mayapy"]  # Supported when publishing from mayapy and the Maya GUI

The executable environment of Pyblish itself will be registered automatically, e.g. python.

This also means that we need an additional member to the API.

import pyblish.api
pyblish.api.current_hosts()

Which returns a list of hosts as string. current_host() will remain as-is, and will return the last-registered host.

Discussion

This addition will have no effect on current plug-ins, but instead open up doors for added functionality, along with support for an arbitrary amount of integrations of both major and minor software packages, including your own home-brewed ones.

3 Likes

Implementing this in 1.1.3 for release on Monday.

It’s due to just having realised that Maya on Linux refers to it’s mayapy as python-bin, thus not registering as Maya at all. And, realising that there will be more of these scenarios popping up, like with Hiero and @tokejepsen just recently, it felt like a necessary next step.

Practically, everything will still work, including current_host (which is now deprecated, read on) with the added requirement that an integration must be loaded for plug-ins to filter against it.

For example, when you load Maya, it’s the Pyblish for Maya integration that registers the host, maya. If this doesn’t happen, then plug-ins filtered by hosts = ["maya"] won’t get run.

You have most likely already done this, as it’s how Pyblish QML automatically registers itself as well, but in the rare case where you are using a host, along with plug-ins filtered by that host, but haven’t registered the integration, you will notice a change in behaviour.

New functions

Like mentioned above, current_host is still alive and well, but is to be considered deprecated, as it will only return the last registered host. I’ve made it so that Maya, for example, registers mayapy, mayabatch, and maya in this order, meaning current_host will still return the expected maya for backwards compatibility.

Henceforth, registered_hosts() is the official method with which to query which hosts are currently supported.

>>> import pyblish.api
>>> pyblish.api.registered_hosts()
["python", "mayabatch", "mayapy", "maya"]

python is automatically registered during initialisation, but can be removed, along with every other hosts, should you need, via deregister_all_hosts().

Here are all the new functions related to this functionality.

  • register_host
  • registered_hosts
  • deregister_host
  • deregister_all_hosts

Any eta on getting this into pyblish-win, or should we be looking to modify the integrations first?

I’ll try and get this in on Monday next week. On holiday here till then.

No rush:) Just wanted to know when I need to worry about this.