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

Installation error in R 4.4.2, Ubuntu 22.04 #2591

Closed
claravdw opened this issue Jan 16, 2025 · 4 comments
Closed

Installation error in R 4.4.2, Ubuntu 22.04 #2591

claravdw opened this issue Jan 16, 2025 · 4 comments

Comments

@claravdw
Copy link

claravdw commented Jan 16, 2025

Trying to install devtools via install.packages("devtools") on Ubuntu 22.04 with R version 4.4.2 gives the following error:

* installing *source* package ‘devtools’ ...
** package ‘devtools’ successfully unpacked and MD5 sums checked
** using staged installation
** R
** inst
** byte-compile and prepare package for lazy loading
Error in .make_numeric_version(x, strict, .standard_regexps()$valid_numeric_version) : 
  invalid non-character version specification 'x' (type: double)
** help
*** installing help indices
*** copying figures
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
Error in .make_numeric_version(x, strict, .standard_regexps()$valid_numeric_version) : 
  invalid non-character version specification 'x' (type: double)
** testing if installed package can be loaded from final location
Error in .make_numeric_version(x, strict, .standard_regexps()$valid_numeric_version) : 
  invalid non-character version specification 'x' (type: double)
** testing if installed package keeps a record of temporary installation path
* DONE (devtools)

Session information:

> sessionInfo()
R version 4.4.2 (2024-10-31)
Platform: x86_64-pc-linux-gnu
Running under: Ubuntu 22.04.5 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.10.0 
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.10.0

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

time zone: Europe/Paris
tzcode source: system (glibc)

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

loaded via a namespace (and not attached):
[1] compiler_4.4.2
@jennybc
Copy link
Member

jennybc commented Jan 16, 2025

Recent versions of R have gained some tighter checks on the input to some version checking functions, so I've certainly seen and fixed related errors in the past little while.

Yet I don't know of any code in devtools that runs afoul of this. Nothing in CRAN checks, nothing in our CI, no other reports of problems.

So I feel like there has to be more to this story, in terms of why you're seeing this but others aren't.

@claravdw
Copy link
Author

Just an update: apparently these errors did not actually prevent the package from being installed. Instead, when I load the package, I see the following:

> library(devtools)
Loading required package: usethis
Error in .make_numeric_version(x, strict, .standard_regexps()$valid_numeric_version) : 
  invalid non-character version specification 'x' (type: double)

But the package seems to be functioning otherwise, for instance I can successfully run:

devtools::install_github("farach/huggingfaceR")

@jennybc
Copy link
Member

jennybc commented Jan 17, 2025

I have the feeling that the error is coming from some package we haven't identified yet (I don't think it's devtools or usethis) but that is being loaded when devtools loads. A sort of global "update packages" would be one relatively harmless thing to try. Because the culprit, whoever it is, has probably dealt with the error and you somehow just have a slightly outdated version of it. This is just a theory but we don't have a lot of information.

@claravdw
Copy link
Author

Yes, you were right--running

update.packages()

fixed the issue!

@jennybc jennybc closed this as completed Jan 20, 2025
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