We’ve been through multiple iterations, but I personally thing that splitting it too much eventually become detrimental to the original aim of making the management easier. It’s a fairly fine line between having enough granularity and not being able to remember where things are and who is responsible for them.
But to your points specifically.
Managing plugins on project and studio level
If I was considering splitting code up based on project it would definitely be project type, but the production reality often shows that shows need individual overrides. That’s exactly why we have, studio and project level cascading setting overrides to cover both cases.
For pyblish plugins for example we have vast majority in the same place grouped by addons, which can be a dcc, or a different integration. That’s the default layer, studio can then add (or technically also override) plugins on a studio level and lastly on a project level, with different location to source them from. In practice, the project level additions and overrides are extremely rare.
I’d argue that if many project level plugins are needed there might be something wrong with the overarching pipeline design. There is of course a value in very specific workflows for a give project, but the expense of managing almost the same, but not quite the same pipelines for various projects grows really high really fast. So we always try as hard as possible to keep the code universal and only abstract out settings that affect it in a reasonable way into the project scope.
Version control of a large plugin collection
We bundle by addon, so essentially by DCC-ish and keep that collection together. At the beginning we were considering versioning individual pyblish plugins too, but truth be told that management overhead just wasn’t viable. Especially considering we’re versioning the full product (or in AYON the individual addons, and their pyblish collections), there’s little value in versioning each tiny piece of code.
That depends how much responsibility those plugins have though. Our pyblish plugins are for the most part fairly agnostic to the rest of the pipeline version. There are data and API dependencies of course, but as far as we keep all the maya plugins together, we’re good.
Also, quite importantly, we practically never use individual plugins in isolation. They need other plugins around them to be useful, hence testing them individually is sometime not possible (outside of unit tests) and probably not very useful.
With move to AYON, we’ll be splitting each addon into it’s own repository, so we’ll end up with around 30-40 repos, which they have their dedicated owner for tracking responsibility. If someone uses the full addon, they should be good to got and it would be possible to have different ayon-maya versions in different projects (even though it’s not pretty), But if you take out and singular pyblish plugin out of that collection…you’re on you own I’m afraid.
