rstudio / packrat

Packrat is a dependency management system for R
http://rstudio.github.io/packrat/
401 stars 89 forks source link

Ignore Custom CRAN Mirror #378

Open kippandrew opened 7 years ago

kippandrew commented 7 years ago

When rsconnect running on RStudio Cloud generates a packrat lock file, it captures our custom internal CRAN mirror/proxy that is set via RProfile.site:

PackratFormat: 1.4
PackratVersion: 0.4.8.1
RVersion: 3.4.0
Repos: CRAN=http://package-proxy

This is problematic when deploying to RSC outside the RStudio Cloud environment, since that internal proxy is not available.

Any ideas for a workaround, perhaps by disabling the capture of the custom CRAN repo?

kevinushey commented 7 years ago

When packrat::snapshot() is called, that Repos: field is populated based on the current value of getOption("repos"). Would it be possible to temporarily reset that option to e.g. the default RStudio CRAN mirror? E.g.

options(repos = c(CRAN = "https://cran.rstudio.com"))
cderv commented 6 years ago

Hi @kevinushey, I jumped on this issue rather than opening a new one. We have also an internal cran mirror for our internal developement environment and we encounter a similar issue : How to deployed to a serveur connected to another repository.

packrat::snapshot() uses getOption("repos") parameter. However, it uses this url to get available.packages in .snapshotImpl. I can't have access to external CRAN on my development environment where I publish from. So packrat snapshot can't work.

Even for deployment with rsconnect (which uses packrat), I can't do that if I can't access the repository.

Do not know if there are solution to snapshot from a repo and deploy with another. I am interesting to follow this subject.

kevinushey commented 6 years ago

Unfortunately, there isn't a very clean way of accomplishing this right now. One way would be to modify the Packrat lockfile at deploy time, to change the repositories to whatever is desired.

The action that updates the lockfile, packrat::snapshot(), updates both the active repositories + the set of used packages for a project, so I'm not sure if that's appropriate to call on the deployment machine.

Supporting this sort of use case will likely require some extra tooling on the Packrat + rsconnect sides.

cderv commented 6 years ago

One way would be to modify the Packrat lockfile at deploy time, to change the repositories to whatever is desired.

I tried that but rsconnect does not use the project packrat snapshot and recreates one (based on local deployment environment configuration) to include in bundleDir that will be pushed to the server. No easy way to modify this snapshot.

Supporting this sort of use case will likely require some extra tooling on the Packrat + rsconnect sides.

I agree on this. I am currently playing with both to come up with a workflow that works for me. Not so easy to understand how one works with the others.

I would like to try to pass through rsconnect my local packrat.lock file to include in the bundle and prevent rsconnect to create an new packrat.lock file. Not a success yet.
I will follow this feed if something new come up. Thanks.