-
Notifications
You must be signed in to change notification settings - Fork 83
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
including renv.lock in writeManifest degrades performance #930
Comments
I think this is the note I have in my personal todo: "check for status() before doing a restore()". I'll take a look this afternoon. |
hadley
added a commit
that referenced
this issue
Jul 24, 2023
Previously we'd always restore the packages from the lockfile, which I had expected to be fast since I had expected the packages to be in the cache. However, this doesn't appear to always be the case, so I instead use a simpler approach where I just force the user to resolve the problem. This means that we can always use the `DESCRIPTION` present in the `.libPaths()` making the code much simpler. Fixes #930
hadley
added a commit
that referenced
this issue
Jul 25, 2023
Previously we'd always restore the packages from the lockfile, which I had expected to be fast since I had expected the packages to be in the cache. However, this doesn't appear to always be the case, so I instead use a simpler approach where I just force the user to resolve the problem. This means that we can always use the `DESCRIPTION` present in the `.libPaths()` making the code much simpler. Fixes #930
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It's not necessarily clear that you don't need to select the
renv.lock
file forrsconnect
to respect it during deployment, but if you do it really slows things down:using latest rsconnect / renv from github:
The text was updated successfully, but these errors were encountered: