`open_output_file` helper about bbr

[seth127]

Given automatic refreshing in RStudio, I'm guessing your feeling is that RStudio users will find these more useful than tail_output and tail_lst?

Exactly. I talked to a few folks at ACoP who were not finding the tail_ helpers that... helpful. And one of them gave me this idea, which I think is a good one.

[seth127]

@kyleam I'm considering trying to sneak in a small bbr release before the next MPN, basically with what I put on https://github.com/metrumresearchgroup/bbr/milestone/28 , and I'm interested in your thoughts. I'm commenting on this issue because I think it is the one that has the potential to get complicated (though I hope not).

My primary motivation here is that we are planning to update the Expo repo to the newest MPN, after the next snapshot, and I would like to be able mention the new open_* helpers (this one and #570 that already merged).

Any thoughts on this are welcome, but the things on my mind currently are:

• Are there any complicating factors in this issue that I'm not thinking of?
• Should this be 1.6.0 or 1.5.1?
• Is there anything else little that we should knock out and include? I looked over the open issues and didn't spot anything, but I may have missed something.

Relevant: #570 is the only that's merged to main since 1.5.0.

[kyleam]

primarily for monitoring runs in progress

Given automatic refreshing in RStudio, I'm guessing your feeling is that RStudio users will find these more useful than tail_output and tail_lst?

[kyleam]

Are there any complicating factors in this issue that I'm not thinking of?

Nothing's popping out to me. The main thing is that it's probably worth reviewing R/read-output.R to try to avoid having duplicate internal logic.

Should this be 1.6.0 or 1.5.1?

I'd say 1.6.0 because it'd have new features.

Is there anything else little that we should knock out and include?

I can't think of anything that need to be prioritized for this release.

[barrettk]

@seth127 Just making a note of it since I didnt see an issue for it, but we may want to include the model_summary() bug for when no directory exists. I know you said you didnt run into this issue at one point on your machine, but may be worth testing for the next release

[seth127]

We're going to hold off on this release for now (probably another week or two, at least) because of other priorities. On this...

the model_summary() bug for when no directory exists.

As you note, I wasn't able to reproduce it with the newest bbr, but I may have been doing something different. See you can reproduce it outside of the diagnostics apps context and, if you can, go ahead and make an issue.

FWIW, I tried to reproduce the error with this and couldn't:

devtools::load_all()

.md <- system.file("model", "nonmem", "basic", package = "bbr")

mod1 <- read_model(file.path(.md, 1))
mod2 <- copy_model_from(mod1)

# these all work for me
summary_log(.md)
run_log(.md) %>% add_summary()
model_summaries(list(mod1, mod2))

# this fails, but that's fine
model_summary(mod2)
# Error in get_output_dir_nonmem(.bbi_object, .check_exists) : ...

delete_models(mod2, .tags = NULL)

[kyleam]

may want to include the model_summary() bug for when no directory exists

@seth127 @barrettk Should be resolved by gh-573 (see first two commits).