pyblish / pyblish-base

Pyblish base library - see https://github.com/pyblish/pyblish for details.
Other
127 stars 59 forks source link

Custom Test #183

Closed mottosso closed 9 years ago

mottosso commented 9 years ago

Goal

To facilitate the implementation of custom tests used in determining when to abort processing.

Motivation

There's been some talk about how one would customise the point at which publishing is aborted, such as whether to continue with Conform is Extraction has failed. This way, the logic behind whether to abort or not is fully in the hands of implementers, and something like Border Control could be implemented on your end before becoming part of the API.

Due to some refactoring work, this is a freebie and will be part of 1.1.

References

A test is any callable that takes a dictionary of variables that defines the current state of operation.

{
  "order": 2, # Order of next plugin
  "errorOrders": [1, 1.4]  # Orders at which an error has occured
}

The state is passed to the registered test and queried for once per plug-in during processing.

if test(**vars):
  # continue processing

A test is registered like this.

def my_test(vars):
    """Don't stop"""
    return True

def my_test(vars):
    """Stop on Wednesdays"""
    if time.ctime().startswith("Wed"):
        return False
    return True

import pyblish.api
pyblish.api.register_test(test)

The default test looks like this.

def default_test(vars):
    if vars["order"] >= 2:  # If validation is done
        for order in vars["errorOrders"]:
            if order < 2:  # Were there any error before validation?
                return False
    return True
BigRoy commented 9 years ago

Had some trouble understanding the concept, but if I read correctly it works like this:

  1. You register a custom function with pyblish, which you refer to as a test.
  2. This function will be called after the process of each single plug-in.
  3. If the test function returns False it stops processing overall, otherwise it continues.

How do we know what is in the current state of operation? What data do we get from that?


Note that you made a typo. At the beginning you have orderErrors where later you have errorOrders.

mottosso commented 9 years ago

but if I read correctly it works like this:

That's exactly right.

How do we know what is in the current state of operation? What data do we get from that?

The test is given vars, which currently consists of this.

{
  "order": 2, # Order of next plugin
  "orderErrors": [1, 1.4]  # Orders at which an error has occured
}

It is updated every time a new plug-in has finished processing. Currently, this is all the information necessary to make enough of a decision about whether to continue processing or not. As time goes, I'd imagine a few more members to be added but so far there hasn't been a need.

Note that you made a typo. At the beginning you have orderErrors where later you have errorOrders.

Thanks, fixed!

mottosso commented 9 years ago

Added to 1.1