Importer/Asset Manager


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.


This is for reference for future development;


Another for reference;


Nice, thanks for sharing!


And of course:)


Proof of Concept


Needs and in PYTHONPATH.



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; Apparently that was added in Qt 5.5, but python-qt5 was build with 5.4. I might be completely wrong about this, @marcus?


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!


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.


Sure. The plan was to maybe make a new class type to inherit from, but maybe thats not necessary.

True, but the problem is that you need to append instances to the parent instance. This allows the UI to not know about the entire hierarchy before showing. Having to load the entire library of a project can easily become a lot to compute, and to wait for.

Maybe I can have a look at a separate model, but it would need to be build dynamicly anyways.

Again the idea was to not have to load the entire context to begin with, so it was necessary to call the process method every time the user expands an instance.

Defo:) All good things to come. As for the button to import, I’d imagined that you attach actions to the instances, similar to how Pyblish works with its plugins. You would then right-click on an instance to gain access to available actions, where one of them could be to import.
I’m imagining that people would use this GUI for updating the existing scene as well, so one plugin for the GUI would be collecting references in the Maya scene that the user can choose to update.

I’ve also imagined that you can get more information about the instances, like for example when collecting the references in the Maya scene, you could see that an instance is out-of-date and there are newer versions available.


I actually just realized that parent could easily be instance. So I’ll have a look at this:)



its been a while since you had this discussion and I just wanted to follow up and see what direction you did take @tokejepsen. Did you manage to borrow any concepts from pyblish for your importer/asset manager and has it been useful?



Hey @bjorn_rydahl

The proof-of-concept is as far as I’ve got with this for now. The mocking module shows as much of the Pyblish concepts as I could currently implement.

The next major issue to tackle will be to implement instance actions;

I also think that the api needs to be separated from the gui, so similar to pyblish-lite and pyblish-qml people would be able to develop their own GUIs.

Are you interested in pushing this further?


It is only investigation so far and I’m just trying to gather what concepts would make sense.

We will probably not use pyblish for it, but may borrow some concepts and use those together with our own actions. The main benefit for using pyblish is the community around it, which is not true for importing :slight_smile:



Yes, I would not bark up this tree. Whenever I see importing made in relation to Pyblish, I make a hissing sound and cross my index fingers.


I agree:)

The more I think about this importer the less it actually really needs Pyblish. BUT I do like the concepts presented in Pyblish, ei. separating collecting data from the action of importing.