ynput
Project Bundles: Workflow enhancements
Intro
This issue is probably touching some backend features and maybe also client side (launcher), but mostly is about how to work with Project Bundles in frontend. I am coming from current state (1.12.4+DEV)
Premise: Main reason for Project Bundles is the ability to "freeze" pipeline configuration per project. By configuration I mean set of addon versions and their settings per project.
Current state is there half-way. The greatest issue (IMO) are now:
Simple way to freeze the configuration
Currently there is now way to fullfil main purpose of Project Bundles. Let me explain by first commenting on what you can do to illustrate what is missing.
You can define Project Bundle in similar fashion as normal project bundle - you define name, launcher and set of addon versions to be overriden from studio production bundle (lets call it like this to differentiate it from the project bundles).
Lets have addon Maya in version 1.4.0 defined in studio bundle. When the same version is used in Project Bundle, side-effects are that any change in studio production bundle will effectively happen in the Project Bundle too - defeating the premise of the frozen configuration.
When you use newer version of Maya addon and then at some point use the same version in studio production bundle and change some settings there, it will affect the project using Project Bundle and thus again defeating the frozen configuration concept.
The only way out of this is to create project overrides but this currently very tedious when you need to do it en-mass - you cannot do it for the whole addon settings or even for the whole bundle. This could be solved by having button next to the addon item in project settings that would do exactly that:
Only with project overrides you can achive frozen configuration per project and because there is currently no easy way to create them, it is one of the major issues.
What project bundle is used
You cannot see what project bundle you use for a given project. You should be able to tell that while you are in the project settings and there should be a way to jump to project bundle settings from project context.
The same goes for pipeline part where you can't really tell what settings you are running at all, making any debugging a nightmare. That could be solved by having project bundle name next to every associated project where there is a project list:
Inherit vs. Override
When creating Project Bundle, you define overrides for every plugin in that bundle. There is no way to say "use this addon from studio production bundle" or "disable this addon completely for this project bunde". You have a list of versions and NONE. But what NONE means is confusing. Does it disable the addon (override) or does it mean it will keep the version from studio production bundle as is (inherit).
These are major issues I have with the current implementation and I am quite confident any studio trying to make this work will hit those. Overriding every setting per project by itself is something a little bit scary, but can be expected when the main goal is to freeze values. We are currently missing some tooling for this to make it less scary (if there is no other solution).
Agreed 100%.
Implementation wise though I have some notes.
Creating and managing project bundles:
I would completely remove all the traces of project bundles from the studio settings pages. It's only confusing and doesn't add anything to the system.
For the edge case situations where a particular settings happens to be only applicable to studio, which could created issues if it's changed outside of the project bundle to an incompatible value. We can provide a quick visual check in the Project settings GUI for correction.
To create a new project bundle we should"
- Show a button to "lock project bundle and settings" directly in the project settings UI
- When the button is clicked, we show a modal asking whether they user wants to only lock addon versions, or also settings.
- After confirming, we
- duplicate current production to a new project bundle
- Name it
original_bundle+Project_nameor similar - Apply this bundle to the project we're working with
- optionally lock create settings overrides on everything if the user opted for it.
That's it, no manual steps and jumping through the hoops.
What project bundle is used
Absolutely, we need to indicate on the project settings page that a project is locked to a specific bundle. I don't actually think we should show it in the launcher at all. It's not relevant to the artist.
Inherit vs. Override
Agreed
I don't actually think we should show it in the launcher at all. It's not relevant to the artist.
I think we should, but only when running dev bundle. On client side, there really isn't any place to know what bundle is used, not even from the console output. I agree that artists shouldn't care, but from th TDs point of view, it is a must. The only way to know in what bundle DCC is launched is to launch it and print AYON_BUNDLE_NAME (or similar) env var in script editor.
Some further findings.
- We need three states of addon project bundle compatibility
- None (addon is older and doesn't even know about project bundles)
- False (Addon doesn't support project bundles)
- True (Addon support project bundles)
True and false can be treated exactly as they are treated right now, however if any addon with project bundles support of None appears in the bundle, this bundle will not be allowed to be set as production to avoid unexpected consequences.
I don't actually think we should show it in the launcher at all. It's not relevant to the artist.
We could just simply only show it in hover over hint and not to show it explicitly in the label. I still feel it could be quite practical to show it on client side not only for developers.
