You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Brainstorm ways to automatically update save_all_plots() #432
So, I think there are, nominally, two ways to think about doing this.
The first is basically to make the function take, as input parameters, lists that correspond to each plot/table function and contain function specific parameters. For example:
Each plot/table specific list could then contain elements corresponding to the input parameters for that function. This is readily extensible and would also allow users to customize plot specific module parameters easily. This does have the downside of requiring adding new default parameters when adding a function, but I dont know of a simple way around that. I have tested this set up and it works, just maybe requires a lot from the user and would probably get unwieldy with more plots.
The second way to do this would involve doing something like below:
Here, we would maintain the standard plotting interface of the individual functions, but users would specify plot specific customizations using a named vector. I have not fully tested this style yet, but dont see why it would not conceptually work.
Regardless of how the inputs are set up, the function itself becomes a pretty simple loop over all available plot_* and table_* functions, with some care taken to set the function specific parameter arguments depending on the input style. It would looke something like:
for(iin seq_along(plottab_functions)){
func_name<-plottab_functions[i]
# print(all_params)func_specific_args<-all_params[paste0(func_name,"_options")][[1]]
func_pars<- c(default_args, func_specific_args)
if(grepl("table",func_name)){
names(func_pars)[which(names(func_pars)=="figures_dir")] <-"tables_dir"
}
# print(func_pars)cli::cli_alert_info("Attempting to execute function: {func_name}")
tryCatch(
{
suppressMessages(
do.call(func_name, func_pars) # Execute plotting/table function
)
},
error=function(e) {
cli::cli_alert_danger("{func_name} failed to run.")
cli::cli_alert("Tip: check that your arguments are correct.")
for(ainfunc_specific_args){
arg_name= names(func_specific_args)[a]
arg_value= as.character(func_specific_args[a])
cli::cli_li("{arg_name} = {arg_value}")
}
print(e)
}
)
}
Thoughts or strong opinions on either of these strategies?
I think I am leaning towards the first more. For this issue, I was more thinking along the lines of trying to automate adding a plot to save_all_plots(). Like creating a GitHub action that would append the new function and format into save_all_plots then open a PR. It would then serve as (1) a reminder to add the plot or figure to the function and (2) a way to add it in without putting much thought. The reviewer of the PR would then need to just adjust input values if it varies from the default.
I think what you said could still be used and applied to the GHA, but it's more of a revamp of the current function if that makes sense. Either way, I like the proposed approaches 😄
@Schiano-NOAA oh okay. Yah, it definitely could be a github action if that's more what you intended. Im not familiar with enough with how GitHub actions works to make that sort of change.
I do wonder whether this type of user input is still necessary for the actual R function. I can imagine scenario where users might want to set a few custom things for a few plots but otherwise get the default versions of everything else.
I should also note that the first implementation above relies on there only being a single function per file, and that the function name and file name match exactly. For example, I do not believe it would work alongside the composition plots in #424, as is.
Activity
JZahner1 commentedon Oct 20, 2026
So, I think there are, nominally, two ways to think about doing this.
The first is basically to make the function take, as input parameters, lists that correspond to each plot/table function and contain function specific parameters. For example:
save_all_plots( dat, plot_recruitment_options =list( module = "TIME_SERIES", unit_label = "mt", scale_amount = 1 ), plot_biomass_options = list( relative = FALSE, ref_line = "msy", unit_label = "mt", scale_amount = 1 ), ..., interactive=FALSE, figures_tables_dir=getwd() )Each plot/table specific list could then contain elements corresponding to the input parameters for that function. This is readily extensible and would also allow users to customize plot specific
moduleparameters easily. This does have the downside of requiring adding new default parameters when adding a function, but I dont know of a simple way around that. I have tested this set up and it works, just maybe requires a lot from the user and would probably get unwieldy with more plots.The second way to do this would involve doing something like below:
save_all_plots( dat, module = c("plot_recruitment"="TIME_SERIES"), unit_label = c("plot_recruitment"="mt", "plot_biomass"="mt", ...) scale_amount = c("plot_recruitment"=1, "plot_biomass"=1, ...) ..., interactive=FALSE, figures_tables_dir=getwd() )Here, we would maintain the standard plotting interface of the individual functions, but users would specify plot specific customizations using a named vector. I have not fully tested this style yet, but dont see why it would not conceptually work.
Regardless of how the inputs are set up, the function itself becomes a pretty simple loop over all available
plot_*andtable_*functions, with some care taken to set the function specific parameter arguments depending on the input style. It would looke something like:Thoughts or strong opinions on either of these strategies?
Schiano-NOAA commentedon Oct 20, 2026
I think I am leaning towards the first more. For this issue, I was more thinking along the lines of trying to automate adding a plot to
save_all_plots(). Like creating a GitHub action that would append the new function and format into save_all_plots then open a PR. It would then serve as (1) a reminder to add the plot or figure to the function and (2) a way to add it in without putting much thought. The reviewer of the PR would then need to just adjust input values if it varies from the default.I think what you said could still be used and applied to the GHA, but it's more of a revamp of the current function if that makes sense. Either way, I like the proposed approaches 😄
JZahner1 commentedon Oct 20, 2026
@Schiano-NOAA oh okay. Yah, it definitely could be a github action if that's more what you intended. Im not familiar with enough with how GitHub actions works to make that sort of change.
I do wonder whether this type of user input is still necessary for the actual R function. I can imagine scenario where users might want to set a few custom things for a few plots but otherwise get the default versions of everything else.
JZahner1 commentedon Oct 21, 2026
I should also note that the first implementation above relies on there only being a single function per file, and that the function name and file name match exactly. For example, I do not believe it would work alongside the composition plots in #424, as is.