-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove {bpmodels} dependency before CRAN submission #97
Comments
Thinking about ways to solve this issue. A few that seems reasonable:
Other less favourable options:
@jamesmbaazam, @Bisaloo & @chartgerink what do you think is best? Another possible solution I didn't list is to take on {epichains} as a dependency to simulate the branching process. In my opinion this doesn't really solve the issue at hand as {epichains} is not on CRAN yet. It is a viable long-term option, to keep in mind. |
As to the best of my understanding of the situation: If the code from option 1 isn't a lot (for example, hundreds of lines), this seems preferable. Once epichains is on CRAN removing would not be too much work so there's also a pathway for ensuring this code is not long lasting and forwards compatible. |
Thanks for tagging @joshwlambert. I agree with @chartgerink. I think the option with the least trouble is (1). The bpmodels code could potentially live in superspreading forever if the {epichains} reparameterizations could cause breaking changes in superspreading. For example, there are plans to reparametrise the infectious period in {epichains}. But I think we could re-assess the engine used here when {epichains} goes on CRAN. |
I agree on option (1). |
Closed as PR #103 is merged. |
No description provided.
The text was updated successfully, but these errors were encountered: