not sure yet how the architecture and workflow works.
seems each check doesn’t run on an instance but on a collection of instances
(in this case all)
i wonder if this could be changed to set the collection to the family and show individual instances?
also curious about making a UI wrapper to run pyblish checks in medic, since the UI is nice.
It’d be cool if you could use it together with pyblish by register_gui(‘medic’)
pick which nodes to fix in UI instead of fix all failed nodes with pyblish actions
the whole GUI?
atm pyblish doesnt support “pipeline configs” out of the box
the closest i can think of is smart use of target / families.
currently i handle this by registering different plugins based on your workflow, depending which menu button you click in maya.
it would be great if we can support pipeline configs that do this, similar to the Karte system.
Visitor: (=context?)
looks similar to the context in pyblish.
you run tests on the visitor, by passing the instances and tests to the visitor.
the visitor also stores the results.
see sample code https://github.com/sol-ansano-kim/medic/wiki#use-medic-module
i’ve had pyblish hang once, but that might be because i also was using the medic GUI at the same time. they both interact with the same medic.pluginManager() so i might have done something that wouldn’t happen if you just use medic for pyblish.
the GUI is super smooth to use, validation runs fast and fixes work well, and lot’s of control.
it seems tightly integrated with the medic plugin / karte system. i wonder if we can “extract” the tests and fixes to work on instances instead of Kartes. (a single instance, which represents a collection of instances).
architecture exploration
logic and GUI seem tightly integrated. not sure if you can run it headless. docs for API
it seems medic uses a custom class to pass nodes. Node
We can get MObject, name of node, MDagPath , MFnDependencyNode,MFnDagNode etc from this node.
so we can convert it to pynode or cmds longnames.
let’s see if we can get access to a list of nodes for every Karte, so we can make instances per node.
update:
i believe the nodes are saved in the visitor instance.
however i’ve decided to not move forward with medic for now. the lack of doc and combination of C with python slows development
and it doesn’t match with my goal of a shared library / package manager, since it requires building a different package for each version of maya.
ideally we have 1 python plugin that works in all mayas (or all dccs)
let’s take it as an inspiration for future pyblish features