Skip to content

1.3.0

Compare
Choose a tag to compare
@mottosso mottosso released this 07 Feb 11:18
· 350 commits to master since this release

Significant changes.

  • Explicit Plug-ins
  • Callbacks



Explicit Plug-ins

This release marks a significant overhaul of the underlying logic of Pyblish. The change is fully backwards compatible and will continue to support the prior ways of working until the next major version change (2.0), but users are recommended to transition and will likely find the change an improvement.

Callbacks

This new feature enables developers to listen for events taking place throughout Pyblish and surrounding applications, such as the GUI.

import pyblish.api

def on_published(context):
  has_error = any(result["error"] is not None for result in context.data["results"])
  print("Publishing %s" % ("finished" if has_error else "failed"))

pyblish.api.register_callback("published", on_published)

For a list of supported events, see here.




What has changed?

Leaving the details of this change to the two links provided above, here's the gist of it. The workflow and mindset of the developer remains the same, but implementation differs in that the superclasses no longer behave differently based on their argument signature.

As you (may not) know, process(self, context) behaves differently from process(self, context, instance). This behaviour was confusing and led to a lot of odd corner cases that were difficult to debug.

Instead, the superclass - ContextPlugin or InstancePlugin - now determines a fixed behaviour for your plug-ins, where their ordering is instead based solely on the order attribute and CVEI provided as named integers, such as pyblish.api.CollectorOrder.

class MyCollector(pyblish.api.ContextPlugin):
  order = pyblish.api.CollectorOrder

  def process(self, context):
    ...

class MyValidator(pyblish.api.InstancePlugin):
  order = pyblish.api.ValidatorOrder

  def process(self, instance):
    ...



Transition Guide

In general, you can simply replace your superclass with the new superclass; either ContextPlugin or InstancePlugin, depending on whether your argument signature contained context or instance respectively.

There is one corner case.

I have both instance and context in my signature.

If so, subclass from InstancePlugin and remove context and instead get the context via instance.context.

def process(self, instance):
  context = instance.context

The plug-in will continue to behave exactly as before.




More changes

  • Simplified CLI
  • Retired vendors
  • Retired file-based configuration
  • Deprecation

Simplified CLI

The command-line interface no longer provides options for file-based configuration and data.

$ pyblish publish

Storing a file called data.yaml in the current working directory when running this command caused the contained dictionary of data to be appended to the Context. This no longer happens.

Additionally, storing a file called config.yaml with plug-in paths would cause the contained paths to be appended to the PYBLISHPLUGINPATH when running the above command. This no longer happens.

Retired Vendors

nose, yaml and coverage are no longer included in this release. If you in depend on them (you shouldn't) then you will have to install them locally henceforth.

nose and coverage was retired due to incompatibility with the forthcoming Python 3 support, and yaml due to no longer having support for file-based configuration.

Retired file-based configuration

At the dawn of Pyblish, plug-in paths were registered by editing a configuration file and storing it in your local home directory. The practice quickly grew cumbersome, as it was difficult to enable networked installs and varying the configuration based on various factors, such as project, software or user.

Instead, environment variables were introduced to take on the weight, and they have been in use ever since.

Hopefully, this deprecation should not affect you and if it does then you find much greater flexibility in instead customising environment variables.

If you still have need for this feature, now is the time to speak up.

Deprecation

Some internal details mostly relevant to developers of Pyblish or software that somehow uses Pyblish to function have changed and are facing deprecation.

  • pyblish.logic.process
  • Services

process was previously used to determine what plug-in to run next and when to stop. But this practice proved too inflexible when it came to the GUI that needed direct control over this particular aspect.

In its place, there is now pyblish.logic.Iterator which simply provides the next pair of items to process, without actually processing them. For your own GUIs, this should prove more flexible, at the cost of having to implement more logic on your own.

See pyblish.util.publish() or pyblish-qml for examples of how to do that.

Services are also deprecated. Their primary reason for existing was to facilitate dependency injection which is no longer needed thanks to the much simplified ContextPlugin and InstancePlugin classes.

If you have need for them, now is the time to speak up.