packrat::restore deletes sources then complains it can't find them #560
Comments
|
To the best of my knowledge, Packrat won't ever try to automatically remove any downloaded source packages from the Is there any chance you could distill this into a small, reproducible example? E.g. using a snippet of code that I could run on my own machine to reproduce the problem. |
|
I tried creating a minimal setup with only a locally installed package. That did not reproduce this behaviour. I did notice however that after a couple of iterations, my locally installed package has multiple source tar balls on the dev system under packrat/src, while on the prod system, after restore, there is only the one current tar ball. Even if I rsync'ed them all over. Could that be at play above? The mechanism which removes sources not used or needed? |
|
I had another stab at this one, this time running the ::restore with strace -e trace=unlink, below is what unfolded. As you can see, right under Replacing |
|
Thanks -- I think I understand what's going on now. When a package is upgraded / downgraded, Packrat attempts to remove the old version of the package, and then install the new one. Part of that implies calling Line 812 in ffd8106 and that will also imply removing all cached sources for that package: Lines 597 to 601 in ffd8106 It looks like this was intentional: but in hind-sight it seems over-aggressive. I don't think we should remove the package sources during a restore; they should only be cleaned up manually (e.g. by the user or by a smart-enough |
|
Ok, then. So is my chosen route for deploying my R based app wrong then? My production system typically doesn't have access to a checked out dev. directory of package sources that my development system has, and from which it can install_local, and I'd be hesitant to provide it. The other R-package-bundle approach is definitely an over kill. We make incremental updates to select few packages, recreating and reinstalling the entire bundle would be an insane waste of time for a small update. If I understand that approach right. But why does it work the other time around? All I have to do, annoying as it is, is to have the restore() process remove the sources, complain loudly that they can't be found after that, then rsync them back, and run restore again, and this time its super happy. The intended pattern for how this should work may or may not be optimal (goes without saying I think it isn't), but it ought to be consistent. |
|
I don't think you're doing anything wrong. Packrat seems to have some unexpected / sub-optimal behavior here, and I think it should work without the extra orchestration that seems to be required in your case. I'll plan to fix this in Packrat directly. |
kevinushey
added a commit
that referenced
this issue
Jun 17, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm experiencing odd behavior.
I using packrat to control the production R environment, but deploying to production and calling restore does strange things. At first go it removes sources of the package I want to restore. It then complains it can't find the sources.
I do the following:
Odd. In my setup this is reproducing every time.
Here is the text output from a terminal as I go through the steps:
The text was updated successfully, but these errors were encountered: