I’ve been moving towards using a single config for all projects in a studio, with the obvious benefit that there’s far less code to maintain.
One of the hurdles to this is that there are ARE certain configurations that currently cannot be abstracted from the shared config on a per-project basis without forking the pipeline-config. The tk-writenode profiles being an obvious one.
I’ve almost implimented a solution that allows us to have optional ymls residing in a config folder in each projects folder where setting overrides can be defined. We’ve managed to do this by adding an additional include in the nuke.yml definition that points to a path with an environment variable for the project folder eg :
includes: - ./tk-nuke-writenode.yml # Pipeline-config based writenode settings. - "$PROJECT_PATH/config/shotgun/settings/tk-nuke-writenode.yml" # Project folder based writenode settings.
This would work if it weren’t for the fact that tk-core implements a validation of include paths, and throws a tankError if the path doesn’t exist. This behaviour prevents SG Desktop from loading as there is no project context when launching SG Desktop, so no project_path.
Am I alone in seeing this approach as being beneficial for how to configure a studios pipeline? Am I storing up problems for myself by complicating where configurations are located?
As I see it, any disadvantage of this approach is easily outweighed by the benefits of having a single config to maintain across an entire studio.
I’m curious to hear your thoughts!
Thanks in advance for your contributions.