Importer/Asset Manager

Pyblish Development
#9

It’s what I figured you meant, but I’m sceptical as to whether it’s a healthy direction to take.

In my experience, importing can get as complex as publishing and I think it deserves as much attention to be done right.

#10

And you don’t think the Pyblish framework is enough?

#11

Here’s an example of what an importer is to me.

#12

Nice example:)

I can easily see this work ontop of the Pyblish framework. I think the main question is whether you think it’s outside the scope of Pyblish?
Don’t want to bend Pyblish to something its not aimed for:)
As I see Pyblish now and in the future, its a framework to execute python based plugin/scripts.

#13

Without getting into too many details about how this would work, I have an overall suggestion.

I thinking of a simple UI that is pretty much the current Publish UI, but with just the instances shown. Right-clicking on the instances brings up the the Actions context menu, where you import/reference/update the asset.

We could obviously look into further features like, searching etc. I this is what our current needs are.

#14

At the moment, only plug-ins support Actions.

What you could do, is add a no-op plug-in, one that does nothing but holds onto actions related to managing the instance. You could give it an order before Collection, such that it shows up at the top, or subclass from Plugin directly.

I’m not convinced using the Pyblish GUI as it is today for these purposes is a good fit and won’t be pushing development in that direction. I’d be happy to discuss a new GUI with a new backend though and be curious to see how you progress.

As a side-note, instances could technically support Actions as well, possibly like this:

# Psuedo code
instance.data["actions"].append(MyAction)
Instance argument for Actions
#15

Good idea, will have a look at that.

I’m not convinced either:) Making a new UI for this was always my intention. I’ll probably hack the current UI, with disguising it, to address immediate needs.
When you say “new backend”, do you mean the commincation with the UI or using Pyblish plugins?

#16

I mean just new everything, no relation to Pyblish beyond them both accessing the same set of files; Pyblish writing, importer reading.

#17

I can’t quite see the benefit of creating something completely new, when Pyblish could function as an output as well as an input?

Unless you already have something in mind for the input part of pipeline?

#18

Yes, I have plenty of things in mind. :wink:

1 Like
#19

So I have had some more thoughts about how the Pyblish framework can work for importing.

Tree Structure
For the user the main thing is to have an overview when loading assets. Having a flat list of assets available for import is overwhelming. The better overview would come from presenting the user with “categories” that they can dive into to individual assets, and this can be represented with a tree structure or parent/child relationship.
Currently in Pyblish there aren’t any tree structures, as the context contains a flat list of instances. So I would suggest introducing hierarchical instances, where you can add instances to other instances.
Practically this would mean you would add a “character” instance to the context, that contains “ryan” and “john”. The user would be presented with a list of one entry “character” that can be expanded to show "ryan and “john” entries.

Instance Actions
@marcus already mentioned the possibility of having instance actions, and this would complete the framework for an asset loader (initial version obviously:))
When the user has navigated to the leaf entries in the tree structure, they can right-click and get presented with different actions to perform on the instance.

#20

Sorry, I completely missed this.

Instances are actually already capable of forming a hierarchy; that was actually the main intent of them being a list to begin with, to have other child instances.

To parent an instance, you’ll instantiate it yourself. Otherwise, it gets parented to the Context, which is the default.

import pyblish.api
context = pyblish.api.Context()
parent = context.create_instance("MyParentInstance")
child = pyblish.api.Instance("MyChildInstance", parent)

Also, just to point it out, the convenience method create_instance is very simple, this is exactly the same thing.

context = pyblish.api.Context()
parent = pyblish.api.Instance("MyParentInstance", context)
child = pyblish.api.Instance("MyChildInstance", parent)

Which might make more sense if you are to deal with hierarchies.

It’s possible we could visualise that in the UI as a tree-view, I think it opens doors for interesting publishing problems as well.

1 Like
#21

Great, one problem sorted:)

Personally I don’t see a need for it in the publishing UI. The importing UI would feature this tree structure though.

#22

This is for reference for future development; https://vimeo.com/147780313

1 Like
#23

Another for reference; http://rocketpipe.vfxmartin.com/

#24

Nice, thanks for sharing!

#25

And https://support.shotgunsoftware.com/entries/95442527 of course:)

#26

Proof of Concept

Usage

Needs GitHub - pyblish/pyblish-base: Pyblish base library - see https://github.com/pyblish/pyblish for details. and GitHub - pyqt/python-qt5: Unofficial PyQt5 via PyPI for Python 2.7 64-bit on Windows in PYTHONPATH.

Run app.py.

Comments

Don’t know what to call this, as its barely a proof-of-concept.

I’m interested in what people think of the initial mocking module, which represents what would be a plugin in Pyblish at some point. There are huge areas of development, like UI and getting Actions involved, but earlier comments the better:)

The idea is to attach actions to the instances shown in the UI, similarly to how plugins currently work within Pyblish.

I opted for QtWidgets to begin with because the current support version of Qt in python-qt5 doesn’t have a TreeView QML type; TreeView QML Type | Qt Quick Controls 1 5.15.9. Apparently that was added in Qt 5.5, but python-qt5 was build with 5.4. I might be completely wrong about this, @marcus?

#27

No, you’re right. It’s time to upgrade soon, that treeview looks great.

Will have a go with this over the weekend, looks cool!

#28

I had a go with this, here are my thoughts.

class InfiniteCollector(object):
    def process(self, parent):
        ...

  1. It would be safe to inherit from pyblish.api.Plugin. Even though it doesn’t get you anywhere in this case, it could help bridge the gap between standard plug-ins and your importer app.

  2. I’m not sure what to think of process taking an argument other than context or instance. This would make it unusable to the overall logic to process plug-ins in order and produce result dictionaries.

  3. The view holds data. I get that it’s easier to start out with a QTreeWidget, but soon you’ll find it easy to get into some bad habits that end up biting you later on.

  4. Calling process yourself is a bad idea. parent.plugin.process(parent.instance) If you can, try getting pyblish.util.publish() involved. It’ll handle triggering of plug-ins in the right order, populating the Context.

Other than that, maybe add a button do actually perform an import, and perhaps a filter to exclude things that couldn’t be imported would be a good next step.