Multiple families workflow

Pipeline Development
#41

Okay, makes sense.

In this particular case, I smell a danger of applying this plug-in to all of your current families, excluding the one you don’t want included, and later you or someone else adding a new family that shouldn’t be included, but would be because of this “catch-all”.

In this particular case, the current explicit method seems a better fit, where the added work pays off long-term.

Let’s come up with at least one more usecase before implementing this.

#42

Hi, I just came up with this, too.

I have a validation plugin for detecting unknown nodes in Maya.
And I love this plugin to be apply to all families like, “No one should ever work or publish with unknown nodes”

But there always have exceptions falling from sky, so it would be nice to have match = api.Exclude for me to work with.

#43

Yeah…, for safety, maybe in my case, I should leave this unknown nodes validation plugin with optional = True for Artist can toggle it off by themself.

And then validate the comment to check if there are any info about why you pass the unknown nodes.

#44

If you did have Exclude @davidpower, how would you use it? It wouldn’t be something an artist could control. It sounds like the optional = True is ideal here.

Alternatively, if you collect instance.data["publish"] = False then it would be toggled off by default. You could, for example, add an attribute to some node, and collect it. This attribute would be something the artist could modify, much like the optional = True toggle in a GUI.

#45

I am not sure about this now, kind of balancing between the developing speed and artists’s convenient, something like that.

But I think it’s not bad if Pyblish implementing this. As long as developer knows what he/she was doing, they can feel free to use it.

Good info, thanks !

#46

No, it wouldn’t be bad. I would just much prefer every single feature of Pyblish to have a clear use case and need. Once we head down the road of adding “nice to have’s” then there’s no turning back. Remember, we can’t ever remove anything from Pyblish, as that would break backwards compatibility. At least not until a 2.0, and even then I’d like to maintain as much of it as I can.

Backwards compatibility is hugely important to me, so we must be confident that whatever we add is here to stay, forever.

1 Like
#47

If someone need Exclude, to prevent confusion, for families term to stay in positive meaning, maybe should put the families that need to exclude into exclude.

from pyblish import api

class DoOtherButNotThose(api.InstancePlugin):
  order = api.IntegratorOrder
  exclude = ["excludeMe"]
  match = api.Exclude

  def process(self, instance):
    # do something

I think the use case of Exclude will only fit for Extraction or Integration, definitely not in Validation stage.

When using Exclude, it’s kind of meaning that “I am not sure the boundary where it will be, but I am sure that I do not want these things, ever”.

So it would be safe that if you only knew what is not you wanted to Extract or Integrate, even the pipeline scale growth and introduce more kind of data type, because you really do not want them like forever.

And it’s not safe to use in Validation, since you need to take care everything carefully during validation, and therefore you must know the boundary where it would be, and with the known boundary, the Exclude will become like Subtract, and that would be meaningless to do this.

Does that make sense ?

1 Like
#48

I believe that is the simplest solution, to have an exclude property on plugins, perhaps a simple case is a Plugin to checks the model version which is referenced on all “asset production stages” except on the modeling stage where it makes no sense to run that plugin.

class ValidateModelVersion(api.InstancePlugin):
    families = ['*']
    exclude = ['modeling']

Perhaps what we need is not a new matching algorythm but a condition inside “plugins_by_families” where having into account the exclude items declared on the plugin.

#49

That’s a good example, thanks for that.

Happy to try an exclude, and I think for it to fit we might need to consider renaming families to include, as that’s what it’d do.

class ValidateThis(api.InstancePlugin):
  include = ["this"]

class ValidateOthers(api.InstancePlugin):
  exclude = ["this"]

Where families could remain as-is for backwards compatibility for the time being.

Happy to see a PR with this.

#50

Thanks Marcus for your quick response.
I like the concept of “family” / “families” when thinking it terms of something being related with an “instance” being more descriptive than “include”, so include what? is the immediate question meanwhile “families” seems to be a more solid concept. Perhaps it might be a little large but “exlucde_families” seems better for me than just a simple “exclude”.

Once more, thanks you Marcus

#51

I see what you mean. I think in that case, it’s either:

  1. include_families and exclude_families
  2. Or exclude and include where the relation to families is implicit

I don’t think we should use, e.g. families and exclude, not when they semantically complement each other so well.

1 Like