Model tree diagram - Githubissues

barrettk commented 3 months ago

Introduces new model_tree() function, allowing you to create a tree diagram for your modeling directory

Some Example function calls

model_tree(model_dir)
model_tree(log_df)
model_tree(log_df, add_summary = FALSE)
model_tree(log_df, color_by = "star")
model_tree(log_df, static = TRUE)

log_df %>% add_summary() %>%
  model_tree(
    include_info = c("tags", "param_count", "eta_pval_significant"),
    color_by = "any_heuristics"
  )

log_df %>% add_config() %>%
  model_tree(
    include_info = c("model_has_changed", "data_has_changed", "nm_version"),
    color_by = "data_has_changed"
  )

Example output

model_tree(log_df,  color_by = "run")

Logical values will be colored as white and red, and are referred to as 'border colors'. The more unique values are added, the more gradient colors between those two border colors are generated.

model_tree(log_df, color_by = "star")

This example illustrates how NA values are handled. Here we color by description (which wouldn't make sense to do in practice). The two distinct descriptions are colored white and red, where NA values are colored grey.

run_log(model_dir) %>%
  add_config() %>%
  model_tree(
    include_info =  c("tags", "description", "model_has_changed", "data_has_changed"),
    color_by = "description", add_summary = FALSE
  )

Previous PR for reference: https://github.com/metrumresearchgroup/bbr/pull/610

andersone1 commented 1 week ago

@barrettk

Can webshot::install_phantomjs() be added to the top of test-model-tree.R

andersone1 commented 1 week ago

[x] model_tree
[x] model_tree.character
[x] model_tree.bbi_log_df
[x] make_tree_data
[x] unnest_based_on
[x] make_model_network
[x] add_log_recurse_dirs
[x] check_model_tree
[x] make_tree_tooltip
[x] color_tree_by
[x] style_html
[x] format_model_type
[x] model_tree_png
[x] print.model_tree_static
[x] req_tree_pkgs
[x] check_for_model_tree_pkgs
[x] skip_if_tree_missing_deps
[x] stop_if_tree_missing_deps

kyleam commented 1 week ago

Most of the check failures are straightforward. I can help take a look at the oldest job failure:

https://github.com/metrumresearchgroup/bbr/actions/runs/9701317535/job/26774698747

   ℹ Creating lockfile '.github/pkg.lock'

  ✔ Updated metadata database: 3.47 MB in 10 files.

  ℹ Creating lockfile '.github/pkg.lock'
  ℹ Updating metadata database
  ✔ Updating metadata database ... done

  ℹ Creating lockfile '.github/pkg.lock'
  ✖ Creating lockfile '.github/pkg.lock' [6.3s]

  Error: 
  ! error in pak subprocess
  Caused by error: 
  ! Could not solve package dependencies:
  * deps::.: Can't install dependency scales (>= 1.3.0)
  * scales: scales conflicts with scales, to be installed
  * any::sessioninfo: dependency conflict
  * any::pkgdown: dependency conflict
  * any::rcmdcheck: dependency conflict

kyleam commented 1 week ago

scales (>= 1.3.0)

1.3.0 isn't on MPN 2023-01-25 (it wasn't released until Nov 2023).

@barrettk is this constraint just copied from ggplot2? Or are we using scales directly in a way that requires 1.3.0 or later? If the former, I think we can drop the constraint, and hopefully that will resolve the pak failure.

barrettk commented 1 week ago

@kyleam It wasn't copied from ggplot2 and I believe I did that because of scales::pal_gradient_n, and there wasn't really an easy workaround. That being said I do have functions set up to skip tests and not run the functions if that version isnt there, so dropping it may still be a good solution.

See req_tree_pkgs, check_for_model_tree_pkgs, and skip_if_tree_missing_deps for details if interested

kyleam commented 1 week ago

I believe I did that because of scales::pal_gradient_n

I see. Then the options I can think of are

remove the constraint and add guards to check it at runtime for the specific spots that need a given version
install a newer scales from elsewhere (as we do for nmrec or mrgmisc)

I think you're going with the first option (no objections from me).

kyleam commented 1 week ago

Highlighting this note, since it won't fail the build:

https://github.com/metrumresearchgroup/bbr/actions/runs/9702122713/job/26777261543

* checking Rd \usage sections ... NOTE
Documented arguments not in \usage in Rd file 'format_model_type.Rd':
  ‘.mod’ ‘msg’

barrettk commented 1 week ago

@kyleam can you take a look at the CI before and after I added collapsibleTree to github actions? A) it seems like it was being installed on mpn-oldest before I added it, and B) clicking the green check is now displaying different/less options.

Edit: the B) I reported was because I accidentally hit 'enter' and didnt realize when I went to commit that change. A) is the only uncertainty

For reference: expected to see collabsibleTree here too

kyleam commented 1 week ago

A) it seems like it was being installed on mpn-oldest before I added it

You don't need the custom step as long as it can be retrieved from the date-pinned RSPM URL.

barrettk commented 1 week ago

You don't need the custom step as long as it can be retrieved from the date-pinned RSPM URL.

Would you recommend reverting this change then, or is there potentially a reason to keep it (some form of risk mitigation)?

kyleam commented 1 week ago

Would you recommend reverting this change then

yes

metrumresearchgroup / bbr

Model tree diagram #673

Some Example function calls

Example output