adding version numbers for packages

[micahwiesner67]

An overdue PR (that is bound to put a smile on @giomrella face to set the exact version of packages for R)
Versions in R are set through inequalities in DESCRIPTION file.

After auditing the packages in the currently installed Dockerfile image, we have the following packages.
R-Version --> 4.4.1

AzureRMR --> 2.4.4
AzureStor --> 3.7.0
cmdstanr --> 0.9.0.9000
cli --> 3.6.3
covr --> 3.6.4
data.table --> 1.16.2
DBI --> 1.2.3
dplyr --> 1.1.4
duckdb --> 1.1.1
EpiNow2 (>= 1.4.0) --> 1.6.1
jsonlite --> 1.8.9
rcmdcheck --> 1.4.0
rlang --> 1.1.4
roxygen2 --> 7.3.2
rstan --> 2.32.6
S7 --> 0.1.1
lubridate --> 1.9.3
readxl --> 1.4.3
tidyr --> 1.3.1
tidybayes --> 3.0.7
optparse --> 1.7.5
Microsoft365R --> 2.4.0

If my memory serves, I believe R generally encourages flexible versioning (i.e. setting minimum versions not exact versions), but I'm open to any approach here if it works.

Update: We also need to update the pkgdown.yaml build to be called from the main dockerfile image for consistency. We see that without updating this we have a failed pkgdown.yaml action in the bdadb49

[github-actions]

Thank you for your contribution @micahwiesner67 🚀! Your pkgdown-site is ready for download 👉 here 👈!
_{(The artifact expires on 2025-08-27T16:28:51Z. You can re-generate it by re-running the workflow here.)}

[micahwiesner67]

Notes from a discussion with Gio and George on 8/27/25

After some initial research from George we have confirmed that

• each rocker image comes with a snapshot repo that should pin the R-version packages that is installed each time (NOTE: we haven't documented which packages are installed but they should be consistent and shouldn't drift --> this was a major concern, crisis averted )

Gio is interested in at least documenting which R version packages are installed. --> this could be done in DESCRIPTION file or also through some CI/CD process that logs any difference in packages installed.

One issue with locking exact versions without specifying an archived snapshot repo is cascasing dependencies. i.e. if package A requires package B and C, 'locking' or specifying the exact version of package A to be installed may not affet the version of package B or C which is installed.

To Do:
George will make a flow chart diagramming our current understanding of how pak installs from different repositories (archived, source vs. binary)
Research pak's lockfile creation and if pak has stable behaviour installing from a lockfile (this theoretically could also allow us to pin R cascading dependencies)
We should put results into the cfa-predict-handbook