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
[fix]: module name selection retained in environment when make_rda = T #421
When saving a plot as an rda package, the module_name that gets selected and retained in order to extract key quantities is saved into the environment. I think this should be removed once the function is finished. I think it should be fairly simple to run rm on the value.
@Schiano-NOAA looks like this is happening because filter_data is using <<- notation when assigning the CLI choice to the selected_module variable (see L809). <<- is a global assignment operator and exports the variable to the global environment. It should be enough to just change these to regular <- assignments (assuming that there isn't some specific reason these need to be global assignments for the selection to work properly.
I think it was designed this way in order to not require the user to select the module again. I think it just needs a rm() at the end of the function so it doesn't stay in the environment.
A rm() call at the end of the function would certainly work. Is the selected_module that was exported being used by other processing functions then (e.g., process_data)? I feel like exporting a variable to the global environmental just so it can be reused by another functions isn't a great design pattern. Its easy to fix either way.
I think it's being used for the rda creation process. I see this being moot though once we standardize module_name across models and probably remove the interactivity altogether.
7. I think it was designed this way in order to not require the user to select the module again. I think it just needs a rm() at the end of the function so it doesn't stay in the environment. @sbreitbart-NOAA this is correct right?
Yes, that's correct. It's used as an argument in calc_kqs() (see, e.g., plot_biomass()). I found that saving it as an object to the environment was a way to save and then use what's sometimes interactive input. Adding rm(selected_module) at the end of the functions appears to be an simple way to resolve this issue.
Activity
JZahner1 commentedon Oct 16, 2026
@Schiano-NOAA looks like this is happening because
filter_datais using<<-notation when assigning the CLI choice to theselected_modulevariable (see L809).<<-is a global assignment operator and exports the variable to the global environment. It should be enough to just change these to regular<-assignments (assuming that there isn't some specific reason these need to be global assignments for the selection to work properly.Schiano-NOAA commentedon Oct 16, 2026
I think it was designed this way in order to not require the user to select the module again. I think it just needs a
rm()at the end of the function so it doesn't stay in the environment.@sbreitbart-NOAA this is correct right?
JZahner1 commentedon Oct 16, 2026
A
rm()call at the end of the function would certainly work. Is theselected_modulethat was exported being used by other processing functions then (e.g.,process_data)? I feel like exporting a variable to the global environmental just so it can be reused by another functions isn't a great design pattern. Its easy to fix either way.Schiano-NOAA commentedon Oct 16, 2026
I think it's being used for the rda creation process. I see this being moot though once we standardize module_name across models and probably remove the interactivity altogether.
sbreitbart-NOAA commentedon Oct 16, 2026
Yes, that's correct. It's used as an argument in
calc_kqs()(see, e.g., plot_biomass()). I found that saving it as an object to the environment was a way to save and then use what's sometimes interactive input. Addingrm(selected_module)at the end of the functions appears to be an simple way to resolve this issue.Remove global environment objects as per #421 (#439)