daaronr / dr-rstuff

Helper files and functions David Reinstein uses across various data projects
0 stars 0 forks source link

Streamlining bookdown templates #10

Open oskasf opened 3 years ago

oskasf commented 3 years ago

@daaronr

Package loading and renv

Proposal: Remove the line which loads packages from base_options.R. Instead we opt to use renv in each project which will ensure that new users have all necessary packages when opening the project.

This would remove the need to load all (now 81!) packages in repos which don't make use of them. Instead we can just load necessary packages for a project (this may initially be slow but will make code more efficient in the long run).

Thoughts?

oskasf commented 3 years ago

This would remove the need to load all (now 81!) packages in repos which don't make use of them. Instead we can just load necessary packages for a project (this may initially be slow but will make code more efficient in the long run).

In fact if we have renv setup in a Repo, we can easily check the dependencies of each file using renv::dependencies(). Then we can identify the necessary packages in a repo by using

packages <- renv::dependencies()
unique(packages$Package)
daaronr commented 3 years ago

One question is will this lead to more mental/cognitive load? When we have a new project, how do we decide which packages to use and thus add to renv? Another thing is that when I start using a package in one project I tend to want it in most all of my other projects anyways.

But it is an interesting suggestion. I was thinking it might be better to just do this approach for the particular packages that are particularly cumbersome and take a long time to load?

On Jun 6, 2021, at 1:53 PM, Oska Fentem @.***> wrote:

 This would remove the need to load all (now 81!) packages in repos which don't make use of them. Instead we can just load necessary packages for a project (this may initially be slow but will make code more efficient in the long run).

In fact if we have renv setup in a Repo, we can easily check the dependencies of each file using renv::dependencies(). Then we can identify the necessary packages in a repo by using

packages <- renv::dependencies() unique(packages$Package) packages_str <- paste(packages, collapse=", ") # Combine vector into string Then this string can be pasted into a p_load(., install=FALSE) statement.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

daaronr commented 3 years ago

Okay, let’s give this a try. Feel free to change this and will see how things go.

On Jun 6, 2021, at 1:53 PM, Oska Fentem @.***> wrote:

 This would remove the need to load all (now 81!) packages in repos which don't make use of them. Instead we can just load necessary packages for a project (this may initially be slow but will make code more efficient in the long run).

In fact if we have renv setup in a Repo, we can easily check the dependencies of each file using renv::dependencies(). Then we can identify the necessary packages in a repo by using

packages <- renv::dependencies() unique(packages$Package) packages_str <- paste(packages, collapse=", ") # Combine vector into string Then this string can be pasted into a p_load(., install=FALSE) statement.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

oskasf commented 3 years ago

One question is will this lead to more mental/cognitive load? When we have a new project, how do we decide which packages to use and thus add to renv? Another thing is that when I start using a package in one project I tend to want it in most all of my other projects anyways. But it is an interesting suggestion. I was thinking it might be better to just do this approach for the particular packages that are particularly cumbersome and take a long time to load?

This additional cognitive load would only come initially at the start of a project, no? As we are only adding packages at the start of a new project.

Also our current method means that collaborators have to add new packages to the template file in dr-rstuff and commit these changes before they can be used in building the bookdown.

But it is an interesting suggestion. I was thinking it might be better to just do this approach for the particular packages that are particularly cumbersome and take a long time to load?

For projects where these cumbersome packages are needed then we would have to go in and add these to said project's workflow anyway.