Skip to content
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

renv::init() is not installing packages from user/system library #2109

Open
radbasa opened this issue Mar 11, 2025 · 1 comment
Open

renv::init() is not installing packages from user/system library #2109

radbasa opened this issue Mar 11, 2025 · 1 comment

Comments

@radbasa
Copy link

radbasa commented Mar 11, 2025

We have discovered a bug in renv::init() of [email protected] or a change in expected behvior from [email protected] for a specific set of circumstances.

  1. A package is installed in the User (or System) Library
  2. The same package is not in the renv cache.

It appears that hydrate() in [email protected] is not properly linking packages into the project library. init() and hydrate() do not show any errors or warnings. This change in behavior happened between 1.0.11 and 1.1.0.

Reprex:

Start with an empty project. WIth one source file.

## source.R
library(dplyr)

To show what is expected behavior, let's use [email protected]

install.packages("remotes")
remotes::install_version("renv", version = "1.0.11")
.rs.restartR()

# Ensure that `dplyr` is in the User (or System) Library
install.packages("dplyr")

# Clear `dplyr` from renv cache
renv::purge("dplyr")

renv::init()

renv::status()
# No issues found

Now, we reset our project to its original pre-renv state.

renv::deactivate()
unlink("renv", recursive = TRUE)
file.remove("renv.lock")

.rs.restartR()

renv::purge("dplyr")

Then we install the latest renv and initialize.

install.packages("renv")
packageVersion("renv")
# [1] ‘1.1.2’

renv::init()

renv::status()
# The following package(s) are used in this project, but are not installed:
# - dplyr

hydrate() is not working as it used to

# renv 1.0.11
> renv::purge("dplyr")
The following packages will be purged from the cache:
- dplyr 1.1.4 [Hash: fedd9d00c2944ff00a0e2696ccf048ec]

Do you want to proceed? [Y/n]: y

- Removed 1 package from the cache.
> renv::hydrate()
The following packages were discovered:

# ~/Library/R/arm64/4.4/library ----------------------------------------------
- dplyr   1.1.4

They will be linked into the project library.

Do you want to proceed? [Y/n]: y

- Linking packages into the project library ... Done!
- Hydrated 1 packages in 53 milliseconds.
> renv::status()
No issues found -- the project is in a consistent state.
# renv 1.1.2
> renv::hydrate()
The following packages were discovered:

# ~/Library/R/arm64/4.4/library ----------------------------------------------
- dplyr   1.1.4

They will be linked into the project library.

Do you want to proceed? [Y/n]: y

- Linking packages into the project library ... Done!
- Hydrated 1 packages in 3 milliseconds.
> renv::status()
The following package(s) are used in this project, but are not installed:
- dplyr

See `?renv::status` for advice on resolving these issues.

We took a look inside hydrate() and further into renv_hydrate_link_packages() and found the following difference:

# renv 1.0.11
Browse[1]> cached
$dplyr
[1] TRUE

# renv 1.1.2
Browse[1]> cached
$dplyr
[1] FALSE
@kevinushey
Copy link
Collaborator

Thank you for the bug report and especially for taking the time to provide a reproducible example! I've reproduced the issue locally as well; I'll investigate and get this fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants