Summary of new features.
- Collectors visible during processing (See animation above)
- More feedback Read more
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.
Say hello to
import pyblish.api 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): assert ...
Like before, these process either the current Context or Instance, unlike before this distinction is made upfront and not decided upon based on the argument signature.
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 -
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
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): ...
Whether you are installing anew or updating, it is recommended that you install from scratch.
For Windows, download and run the installer or install via the command-line.
For Linux, OSX or to install via the command-line, see manual installation instructions here.
If you run into any issues, feel free to post below.
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)
Thanks to this change, you will now find the toggled state in the GUI properly reflected in the physical
instance within your plug-ins; meaning you can now make considerations based on their visual state!
To try it out, have a play with this example, printing the current state from the GUI.
import pyblish.api import pyblish_integration class MyCollector(pyblish.api.ContextPlugin): order = pyblish.api.CollectorOrder def process(self, context): context.create_instance("myInstance1") context.create_instance("myInstance2") count["#"] += 1 class MyValidator(pyblish.api.ContextPlugin): order = pyblish.api.ValidatorOrder def process(self, context): for instance in context: print("%s['publish']: %s" % (instance.data["name"], instance.data.get("publish", True))) pyblish.api.register_plugin(MyCollector) pyblish.api.register_plugin(MyValidator) pyblish_integration.show()
For a list of supported events, see here.
Also have a look at the new chapters in Pyblish by Example
In general, you can simply replace your superclass with the new superclass; either
InstancePlugin, depending on whether your argument signature contained
There is one corner case.
I have both
contextin my signature.
If so, subclass from
InstancePlugin and remove
context and instead get the context via
def process(self, instance): context = instance.context
The plug-in will continue to behave exactly as before.
- Simplified CLI
- Retired vendors
- Retired file-based configuration
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.
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.
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.
Some internal details mostly relevant to developers of Pyblish or software that somehow uses Pyblish to function have changed and are facing deprecation.
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.
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
If you have need for them, now is the time to speak up.
With the change from
pyblish-base, you may be wondering…
Will the import path change?
No, you will still import like this:
pyblish-base is only visible and relevant on GitHub.
Can I still install via pip?
Yes, installation remains unchanged.
$ pip install pyblish