I feel like Pyblish has reached a very stable version, where there are only improvements and more applications to add, so I would like to start the discussion about where people see Pyblish go next.
There are numerous issues for improvements and features, but I think Pyblish is missing a goal for next iteration.
If Pyblish is about pipeline and workflows, I personally see an area where Pyblish is lacking; sharing plugins.
In the current state of Pyblish there are plenty plugins to gain insight from or pull into your own workflow, but its always a matter of copy/pasting and adjusting the code. In order for everyone to truely share plugins and being able to insert new plugins into a pipeline I think these issues need to be tackled; https://github.com/pyblish/pyblish-base/issues/143 and https://github.com/pyblish/pyblish-base/issues/123
I’m flying back from holiday in a few days, I’ll have and think about how to contribute to this line of thought till then. An “app store” of plugins should be fairly straightforward at this point thanks to the mentioned stability, and at that point I think we’ll be able to highlight some of the difficulties and importance of writing loosely coupled plugins.
I’ve given this some thought and have come up with a suggestion for a step in the direction of shareable plug-ins.
On the developer-end, in any GUI, it would appear as a + button that open an explorer. In this explorer is a list of all plug-ins produced by anyone who made and registered one in a central registry. The developer could then pick any number of plug-ins to include in the current publishing session.
The idea would be that this would be a quick way of evaluating other plug-ins in a new environment - yours - before going ahead and installing it. Installing it would then be a matter of downloading it onto a PYBLISHPLUGINPATH as any other plug-ins, where each plug-in or plug-in collection would/could have it’s own documentation and so forth.
I think the step of having a “rapid prototyping” method of evaluating plug-in is important, especially during early days of getting to terms with how plug-ins can truly be independent of the environment in which they were developed.
Technically, plug-ins are already read as a file and passed to exec, which means we could easily and transparently load text via the web and pass that to Pyblish at run-time without restart. Plug-ins could then be registered as plain text in something along the lines of Firebase where we could also view and edit those plug-ins.
Later on, once we’ve established rules and best practices on how to write shareable plug-ins, odds are we won’t need this initial prototyping phase as much, but I would still expect it to be the go-to first step in evaluating any plug-in.
The work required would be (1) a central spot, such as Firebase which is free and easy to get setup and (2) a GUI for visualising and browsing the plug-ins. Assuming (3) the act of actually loading and running the plug-in at run-time is straightforward.
Sounds very cool to be able to evaluate the plugin before installing it.
What are your thoughts on the install process into the persistent PYBLISHPLUGINPATH?
As an advanced user I’m biased to installing git repositories etc., but I would imagine for most users this is troublesome.
I’d probably start by introducing a common default, such as a .pyblish folder in the user’s home directory. That way, the user has write permissions and won’t have to register any additional paths. Plus it’s easy for us to setup.
The interface through which plug-ins are installed could be achieved through the same GUI, something along the lines of Make available offline but instead call it Install or the like. Under the hood, I’d imagine something along the lines of this…
$ pyblish install that_magical_plugin
Mimicking that of pip install, which further under the hood would be a Python CLI.
$ python -m pyblish install that_magical_plugin
Finding and browsing for plug-ins is where a web front-end comes in, for which I’ve always had in mind something along the lines of https://packagecontrol.io/. As specified in the original issue - #123.
I love the capabilities of pyblish but would love it even more if you were to expand to software’s that don’t use python coding such Unity3D. I’m currently in the works to try and output from Unity and into pyblish to run checks but it is no easy task.
@mrobbins I would love to chat with you about this, I’m interested in seeing support for that too. Supporting other languages has been a goal since day one, but so far there hasn’t been interest; apart from minor Javascript for the Adobe suite, that later turned out to also support Python.
If you are interested, I’d be happy to help put put together implementation for your language of choice, such as JS, C# or Lua. The main GUI, pyblish-qml, is language independent and would run identically in any language. What we’d need is the run-time component of Pyblish, which shouldn’t be too challenging to get off the ground.
@marcus Yes, I would be very interested to discuss further of creating some implementation here. I currently use C# so if we could get that off the ground that would be amazing. Thank you for the interest in expanding.