Pyblish Collect then Validate

Support
#1

Hi

A question about running through the Pyblish Stages one by one.
I have looked at this page.
https://pyblish.gitbooks.io/api/content/pages/util.validate.html

context = pyblish.util.collect()
pyblish.util.validate(context)

I expected that the collect would obviously run the collection and return the instances, which it does, but also that when I then pass the instances/context through to the validate it wouldn’t then run the collect again?

But it seems it does, I have a print in my collecting plugin and it prints both at collect and validate stages. Is this correct? What is it using the context for?

thanks

Phil

Side note:

I think I’m trying to produce something similar to what Mattias from Ftrack is producing.
I want to control the various stages. 1st user chooses a publish preset. The preset then runs the filtered collect plugins. A second custom ui specific to the preset and the collected data is displayed to the user. Then it goes onto validate the collected instances. Displays validation warnings, and gives user chance to continue or back out. Then carries on with the normal extract and integrate phases.

#2

Ah I think I have a solution.

Am I right in saying it is up to me to check within the collect plugins, the context being passed to me for instances already created before by this plugin?

So my collect plugin should check the context for preexisting instances first before creating new instances.

#3

Hi @Philip_Scadding,

You are right in that pyblish.util.validate() includes Collection, so running pyblish.util.collect() and then pyblish.util.validate() would effectively run Collection twice.

But I think you’re right that it should behave as you expect it to. validate() should only validate, extract() should only extract and so on. I’d go ahead and implement it as such right now, if it wasn’t for the fact that the way they act currently has been in action for quite some time. I’m honestly surprised this problem hasn’t come up sooner, actually.

I know these convenience functions aren’t seeing much use, as publish() is the most used function and the GUI usually handles more complex cases, so that could be one reason.

What do others think about making the CVEI convenience functions behave as @Philip_Scadding expects them to? That is, to be able to run this:

from pyblish import util, api

context = api.Context()
plugins = api.discover()

util.collect(context, plugins)
util.validate(context, plugins)
# Optionally, manually check for errors here..
util.extract(context, plugins)
util.integrate(context, plugins)

It would enable the development of simple GUIs such as this one, and I can’t see it taking away what is currently made possible by their current behavior.

Thanks for bringing this up @Philip_Scadding. To quickly test this out on your end, with your GUI, to see whether it makes sense, try replacing the util._convenience function with this.

def _convenience(order, context=None, plugins=None):
    plugins = list(
        Plugin for Plugin in (api.discover() if plugins is None else plugins)
        if lib.inrange(number=Plugin.order, base=order)
    )

    return publish(context, plugins)

If you find that this makes sense, then I think we should have a look at making it the default.

So just to clarify, that no, you should not need to do this.

#4

Thank you for getting back so fast.
Yeah I can understand your hesitancy to change it after it being there for so long.
That said I’m not sure that the way it currently is, is much use to people. If you pass a context to any of the convenience functions it will duplicate the instances, which I can’t imagine would be beneficial to anyone. You never know, but it would be odd to rely on that behaviour.

The code you posted now has the behaviour that I expected, so I’ll use that for the time being.
Thank you.

#5

Yes please! This is actually according of the lines what I discussed before on Gitter where I wanted to collect and then alter some states by code (e.g. disabling some instances) and proceed with validation of those.

#6

I’m excited by this change, I made a pull request with the behavior here.

1 Like
#7

I’ve merged this change and think it looks solid.

It’ll make it into the next release, unless we find something off about it before then (no scheduled release yet).

Thanks guys for pointing this out and making these suggestions!