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

Error when installing 1.12.0 in packrat #3329

Closed
diegogruber opened this issue Jan 29, 2019 · 9 comments
Closed

Error when installing 1.12.0 in packrat #3329

diegogruber opened this issue Jan 29, 2019 · 9 comments

Comments

@diegogruber
Copy link

I've been using data.table 1.11.8 within a packrat project with no issue. After updating to 1.12.0 I get the following error on package load:

Error: package or namespace load failed for ‘data.table’:
 .onLoad failed in loadNamespace() for 'data.table', details:
  call: fun(libname, pkgname)
  error: This data.table installation appears to be faulty; tools::checkMD5sums returned FALSE. Please close all R sessions and reinstall data.table.

After downgrading back to 1.11.8 the error disappears. I've tested this on other people's machines so I'm pretty confident this is not particular to my system. I have not experienced this issue with other packages either. For that reason I believe this is an issue of the latest data.table version and not a problem with packrat, but I might be wrong.

Here is how I've managed to reproduce the problem (on Windows 10):

First create a new project in RStudio and open it, then run the following code:

install.packages("packrat")  # Install packrat 0.5.0 if needed
packrat::init() # Initialize a packrat library
install.packages("data.table") # Install latest version 1.12.0 of data.table
packrat::snapshot() #Take a snapshot of the current library
library(data.table) # Attempt to load the package

Here's the output of sessionInfo():

R version 3.5.2 (2018-12-20)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)

Matrix products: default

locale:
[1] LC_COLLATE=Spanish_Spain.1252  LC_CTYPE=Spanish_Spain.1252    LC_MONETARY=Spanish_Spain.1252
[4] LC_NUMERIC=C                   LC_TIME=Spanish_Spain.1252    

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
[1] compiler_3.5.2 tools_3.5.2    packrat_0.5.0 

Thanks for your help! Hope this can be resolved in upcoming versions.

@MichaelChirico
Copy link
Member

MichaelChirico commented Jan 29, 2019

@diegogruber Can you confirm you've obeyed the advice?

Please close all R sessions and reinstall data.table

Pinging @kevinushey since it may help to know what exactly packrat is doing on the backend during package upgrade

@mattdowle
Copy link
Member

mattdowle commented Jan 29, 2019

I've run the steps but it works fine here on Ubuntu.
Can you try outside packrat please, @diegogruber ? Close all R session to release any locks on the datatable.dll. Then in a fresh R session do install.packages("data.table") followed by library(data.table). If that works then it is something to do with packrat. Maybe packrat is adding something to the package and changing the MD5, @kevinushey? But if that were the case, I would expect it to fail on Ubuntu too. But it doesn't fail : packrat works fine here on Ubuntu. So I'm at a loss.

@mattdowle
Copy link
Member

mattdowle commented Jan 29, 2019

data.table now calls tools::checkMD5sums("data.table") on load and fails if that returns FALSE. Please run that yourself to confirm it returns FALSE. For me on Ubuntu it returns NA so that's why it works here where I unstall all packages from source. It's likely this is something Windows-only to do with the Windows binary perhaps? I don't have Windows easily accessible so we'll need your help to investigate what's going on please with this packrat interaction.

@mattdowle mattdowle added this to the 1.12.2 milestone Jan 29, 2019
@diegogruber
Copy link
Author

diegogruber commented Jan 30, 2019

Thanks everyone for your replies. If I am in a fresh R session with the standard user library (no packrat) I can load data.table 1.12.0 without issue. Also tools::checkMD5sums("data.table") returns TRUE, so this does seem to be packrat-related. While messing around trying to fix this issue I remember getting an error that might be of help, but I haven't been able to reproduce it. If I remember correctly, it said there was a checkMD5sums mismatch between the data.table description file and the packrat lock file. As I mentioned previously, this has only happened with this specific version of data.table. Hope that helps!

@diegogruber
Copy link
Author

Update to my last comment. If I remove and then reinstall data.table on the packrat library I can load it fine. It is only after I run packrat::snapshot() that the problem returns. Then, if I run tools::checkMD5sums("data.table"), I get the following message:

file ‘DESCRIPTION’ has the wrong MD5 checksum
[1] FALSE

@jangorecki
Copy link
Member

linux here and also not reproducible

@mattdowle
Copy link
Member

Thanks for the info. Glad this is cleared up.
Suggest we downgrade the error to message and include a suggestion that user runs checkMD5sums() themselves. I considered warning, but warning seems too strong given it's packrat.

@mattdowle mattdowle changed the title [bug] Installing 1.12.0 in Packrat Error when installing 1.12.0 in packrat Jan 30, 2019
@cderv
Copy link

cderv commented Jan 30, 2019

I can reproduce on Windows 10.

the issue is indeed with DESCRIPTION file that packrat modifies when creating the project library. Basically it add some informations about packrat version used for this package installtion, the source of the package and a hash (for caching purposes I think).
This is happening in packrat::annotatePkgDesc() called in the snapshot process.
So this check in .onLoad is indeed too strong for packrat mechanism. a message will work, but it will be printed all the time if used with packrat as the DESCRIPTION file will always be different.

However, I do not explain why this does not happen during the test in linux system, as this function and mechanism is not os specific.

@mattdowle
Copy link
Member

Ok I'll just remove the MD5 check. It was added as an attempt to detect #3056. But since that attempt I put in a better way using Cdllversion. So it makes sense just to do away with the MD5 check given these problems.

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

No branches or pull requests

5 participants