The last release of the pyblish metapackage was made in September 2018. All of the sub-projects have evolved a fair amount since then so would it be worth making a new release?
Alternatively, if nobody is bothering to use that metapackage would it make sense to abandon it and take it down off of github and pypi?
Not sure who is using it. Think the development speed left it behind for most people, although now it’s slowed down and become more stable it might a good starter pack.
I like the idea of having a “blessed” collection of stable packages that are known to work together. However, if package compatibility isn’t really an issue in practice and/or can be managed at the sub-package level, it seems like a somewhat redundant abstraction.
It’s redundant I think.
It’s been in an odd position since the start; initially, development between the various packages were at conflict with each other, Maya requiring one, QML another and Nuke a third. So the metapackage was introduced. But because development is never finished, it was never clear when to update it.
And now that development is stable and compatibility as wide as it’ll ever be, there’s little need for it.
Should we take it down though? I’m not so sure.
I figure, to anyone just entering the Pyblish arena the word “base” and “lite” etc. won’t make sense. They’ll want “pyblish” and so to them it’d make sense to pip install pyblish. Then if not everything is the latest and greatest isn’t really a problem. Once they’ve decided to continue using it, they’ll be well versed enough with “base” and “lite” that they’ll spot newer versions for it.
On top of that it makes tutorials easier to write, getting up and running with Pyblish without first having to explain how we’ve separated the various parts internally.
At leas that’s my train of thought for it, what do you think? The page is clear enough about it I think.
But yes, an update certainly makes sense. I think the latest of all packages are in a good state as-is, I’ll make that happen now.
As to whether anyone’s using it, there appears to be some traffic surrounding it.
https://pypistats.org/packages/pyblish
Downloads last day: 2
Downloads last week: 176
Downloads last month: 212
Almost as much as base itself.
https://pypistats.org/packages/pyblish-base
Downloads last day: 14
Downloads last week: 97
Downloads last month: 355
I think it does serve a useful purpose. If it’s not obvious when to do feature based releases for the metapackage maybe it would be better to do time based releases? A release once a year or so seems like it would be enough to keep it reasonably up to date.
Ah, I’m not sure the development schedule is regular enough for a time-based release schedule to make sense. If we had sprints and made consistent progress each week or month, it would make sense I think. But if the amount of gain per release isn’t consistent - which it isn’t, since it’s being progressed on a free-time schedule - I think it can devalue updates with more important changes if most updates are just to keep in sync with time. IMO updates should happen when there’s something worth updating, such that when you see a new release, you know it was something worth releasing.
I don’t know. Maybe I’m not seeing the problem really. pyblish/pyblish is meant as an entrypoint for new users, whereby advanced users can cherry-pick additional packages and versions on-demand. In that sense, I think what we’ve got now is pretty well-balanced.
I would say, continue to submit PRs with suggested updates, I think that’s a good mechanism for determining whether or not an update is necessary. If nobody asks for it, then that’s a pretty clear signal no update is needed; as is the case with e.g. the Houdini package which is more or less superceeded by having Houdini-relevant functions embedded into the QML GUI.
How does that sound?
That’s why I was thinking of a relatively long release schedule, e.g. annually.
Fair enough, but then I guess my question would be: What changes would qualify as making it worthwhile to release new pyblish versions?
We’ve been using the previous pyblish release as a meta-dependency instead of tracking the newer individual packages so I don’t know what significant changes have been made recently. In other words, I didn’t start this thread because I thought there were changes that needed to be released, I just thought that given the amount of time since the last release there had to be something good in there 
I don’t think there is a problem. Mostly I’m just trying to get a handle on how I should conceptually be thinking about pyblish. I had been thinking of it as a “stable” release of the sub-packages, but as you implied, there isn’t really a formal testing-release process so that’s probably not quite right. It’s more like a recommended list of starter packages.
Interesting, we’ve been using pyblish-lite in Houdini so I wasn’t aware of this. Do you happen to have a link where I could read up on the changes? I probably missed it, but I didn’t see anything obvious mentioned in the release notes when I looked back through them just now.
This also raises another question though. If pyblish-houdini is mostly superseded should work be done to completely supersede it and remove it from the recommended package list, i.e. pyblish?
One of the things I think Pyblish could do to be a little more approachable is make it easier to determine which parts of the ecosystem are currently developed. If I look at the pyblish org on github it contains 59 repos, but once you get past the first 2 or 3 (pyblish-base, pyblish-qml, maybe pyblish-lite) it’s pretty tough to tell which ones are worth looking at as a new user/potential developer. Even as someone who’s pretty familiar with the history of the project there are several repos in there that I’m pretty sure are obsolete, but I"m not 100% sure.
Best,
It’s a tough one. 
I think we’ll know when we see it. For example, this just came up for the Avalon project.
Once that’s merged, I would make a new release with some juicy release notes.
I’d say the same.
For any release, there will be release notes on GitHub, such as these.
But in general for most integrations, the added value is a menu item, a registered host and generic plug-ins. Initially, the idea was to expand on those generic plug-ins as something to build on. But writing plug-ins have generally been straightforward enough that people just write their own. The same goes for menu items, where studios seem to prefer an item in their own pipeline sub-menu. And registering a host is a one-liner.
QML used to require more however. Because it runs in a thread, integrations also needed some way of communicating with it, via e.g. maya.cmds.executeInMainThreadWithResult. But a while back, those requirements were embedded into the QML project instead, as it enabled people to use QML without an integration. It made QML more generally accessible.
I can see what you mean. I’ve looked at that list with the mindset that projects without recent activity are to be avoided. And that keeping projects around helps keep track of where we’ve been, for when a new idea comes to mind and one is searching for reference of whether something’s been tried before and is fo what and when.
So I probably wouldn’t have them removed, but there’s an “archive” feature of GitHub we could potentially use. That way, it’s clearly marked as “part of history” without loosing track of that history.
How does that sound?
Appreciate your input @jedfrechette, these are the kinds of concerns that keep a software project on its toes!
I think that would work, or even just put a prominent note at the start of the README that they’re deprecated, e.g. like pyblish-rpc has.
I’m not sure how useful the placeholder repos like pyblish-blender and pyblish-advance are. I guess they’re aspirational, but couldn’t those just be recreated if/when somebody is ready to contribute code?
I think that sounds like a good idea! Next step is someone finding the time and taking initiative.