1.4.1

register_gui

This release enables use of multiple GUIs and eliminate dependency on pyblish-integration and pyblish-qml from host integration packages, like pyblish-maya

Implementation

A new function is introduced, where a developer may build a GUI and register it with Pyblish. An integration may then query registered GUIs and attempt to open the most suitable one.

• http://api.pyblish.com/register_gui.html

Also see:

• pyblish/pyblish-qml#204
• pyblish/pyblish-maya#57

1.4.0

Version 1.4.0 - Steel

• Enhancement: All major objects now boasts unique IDs for increased stability (#266)
• Enhancement: Stability improvements; Context and Instance are now much closer related (88478e9)
• Bugfix: InstancePlugin collector will error out util.publish() with multiple instances (#268)
• Enhancement: Simplified Iterator (#264)

1.3.1

Maintenance update, see the 1.3.0 release for details.

1.3.0

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.

• Discussion
• Issue

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.

• Supported events

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.

1.2.2

• Added icons for integrations under /icons
• Added support for instances with multiple families (#231)

Multi-family support

This update adds the ability to provide instances with more than a single family.

Traditionally, an Instance would only support having a single family. This family is then matched against supported families of each plug-in. Now, an instance can register multiple families; essentially changing places of how plug-ins and instances are matched. That is, instead of building a plug-in with support for multiple families, you can now think in terms of building instances with multiple families, and in that way register support for more than a single plug-in.

See the issue for more details.

74

Automated release from AppVeyor

1.2.1

Version 1.2.1

• Feature: Actions (see #142)
• Enhancement: Added deprecation warnings; quiet by default, run Python with -Wdefault to see them.
• Enhancement: In favour of maintainability, the dict-like property of Context was simplified; no behavioural difference.
• Enhancement: Multiple instances of the same name now officially supported.
• DEPRECATED: Context/Instance .data is now a pure dictionary. (See #117)
• DEPRECATED: Context/Instance .add and .remove

1.1.6

Version 1.1.6

• Bugfix: Duplicate instances was allowed (#219)
• Added pyblish.plugin.plugins_from_module

1.1.5

Version 1.1.5

• Bugfix: Deprecated function pyblish.api.current_host fixed (#215)

1.1.4

Version 1.1.4

• Feature: Added support for "MyInstance" in context
• Enhancement: Removing the need for @pyblish.api.log (#213)
• Bugfix: Negative collectors (#210)

Context.contains

The Context can now be directly queried for the existence of an Instance.

>>> context = Context()
>>> instance = context.create_instance("MyInstance")
>>> "MyInstance" in context
True
>>> instance in context
True
>>> "NotExists" in context
False

@pyblish.api.log

You now no longer have to apply the decorator @pyblish.api.log to your plug-ins for logging to correctly reflect the current module and plug-in name in its records.