Thanks for the suggestion Jean-François, but I think this is a bit of a non-starter. The fact is it checks if the path exists, and raises a tankError if it doesn’t. I don’t see how leveraging platform specific paths might allow an absolute path that you want to work, to work(eg not raise an error), if the file doesn’t exist.
It’s interesting that this approach was taken to handle problems of making include multi-platform, but it’s not really an elegant solution; tt feels like you’re trying to provide convoluted solutions to a problem of your own creation; eg not entertaining the idea of all includes being optional.
I really don’t see the problem with allowing include paths that don’t exist if the fact they don’t exist is clearly logged. It’s not like there haven’t been other farm more serious problems that only reported a log rather than an error when encountered (eg for example when a local cache was locked preventing an updated config from bein cached to users… resulting in pipeline updates randomly not being picked up by users! ).
Your suggestion definitely would work. The first suggestion is a pretty heavy handed syntax, so I’d prefer the second suggestion ?path/to/optional/include.yml which is nice and simple.
Would square brackets also make sense? That takes the same syntax logic as the template system.
includes:
- path/to/mandatory/include.yml
- [$PROJECT_PATH/path/to/optional/include.yml]
The ? makes me think of tcl, so would be more along these lines :
includes:
- path/to/mandatory/include.yml?$PROJECT_PATH/path/to/optional/include.yml
Which would equate to:-
path/to/mandatory/include.yml? or if it exists $PROJECT_PATH/path/to/optional/include.yml
But I prefer the square brackets approach.
1 Like
I’m currently toying with my own solution which basically replaces the whole dirpath of a yaml file (in each environement file) to be based on a environement variable for each yaml file.
Then I check a override folder to see if a yaml file with that name is present and then change the override env to point to that folder. (if not it will just point to the default settings folder inside the shotgun config)
This requires all yaml files to have a new include that points to a/several env variables which all need to be set in the pipeline_config_init.
It works fine so far and is quite flexible.
However this would replace the yaml file for the override instead of include it to override.
I’m wondering if overriding is better than including for some of these.
I didnt actually know until I tried it that you can include another templates file (i.e. project_templates.yml) which will add to your exisiting templates.
Opens up a whole world of possibilities.
But I’m still not entirely clear how overrides work, I managed to add more paths.
1 Like
Some screenshots of my setup:
Our software configs (including shotgun) live in a hidden “_configs” folder in the project root, divided by software name.
The settings folder here will hold a folder for each pipeline config name. I usually have a primary and a beta (cloned from pimary) and push changes from beta to primary.
The way I’m setting up the override system is to be able to toy with overrides in the beta without affecting everyone else.
The .example files are pure filecopies of the original config files.
If we want to make an override we simply rename the file back to .yml, reload the desktop pipeline config and voila, override is active.
For me it’s important to give our leads and supes an easy way to override certain pipeline behaviour (without really giving them access to the installed shotgun pipeline), the simplest of things being mantra setups and nuke writenodes and the knobs they promote.
This way I can hopefully keep 1 config up to date, perhaps make it distributed, and set up new shows very quickly. Then leave most of the software setup to the leads.
1 Like
@jfboismenu did this optional include feature ever make it into tk-core? I think our studio can make use of it for the same reason described by @Patrick.
Unfortunately no, it never made it in.
I’ve started using Git Branches of my main setup to keep projects separate and just deal with adding new features by carefully merging things.
And for various other things I am now using CPENV to keep the pipeline config clean of things that dont belong there.
1 Like
i’m gonna revive this… because optional flags for yaml files is exactly what i’ve been wanting in my life… for… awhile… is this still just off the roadmap?!
1 Like
