Closed dipterix closed 4 months ago
AFAICT this is the first time anybody has seem this behavior, and considering that pak is used a lot in GitHub Actions, it is probably caused by something specific to your system.
What is the output of pak::pak_sitrep()
?
What is the output of sessionInfo()
?
What is the output of getOption("repos")
?
Can you show the DESCRIPTION
files of some of the broken packages?
What is the output of Sys.getenv("tar")
?
What is the output of system2(Sys.getenv("TAR"), "--version")
?
Sure!
#> pak::pak_sitrep()
* Version information:
- pak platform: x86_64-apple-darwin20 (current: x86_64-apple-darwin20, compatible)
- pak repository: - (local install?)
* Optional packages installed:
- pillar
* Library path:
- /Users/klab/Library/R/x86_64/4.3/library
- /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library
* pak is installed at /Users/klab/Library/R/x86_64/4.3/library/pak.
* Dependency versions:
- callr 3.7.3
- cli 3.6.1.9000
- curl 5.2.0
- desc 1.4.3
- filelock 1.0.2
- jsonlite 1.8.8
- lpSolve 5.6.20
- pkgbuild 1.4.3
- pkgcache 2.2.1
- pkgdepends 0.7.0.9000
- pkgsearch 3.1.3
- processx 3.8.3
- ps 1.7.5
- R6 2.5.1
- zip 2.3.0
* Dependencies can be loaded
#> sessionInfo()
R version 4.3.2 (2023-10-31)
Platform: x86_64-apple-darwin20 (64-bit)
Running under: macOS Sonoma 14.3
Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRblas.0.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRlapack.dylib; LAPACK version 3.11.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
time zone: America/Chicago
tzcode source: internal
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.3.2 fastmap_1.1.1 cli_3.6.2 pbdZMQ_0.3-11
[5] pillar_1.9.0 glue_1.7.0 utf8_1.2.4 fansi_1.0.6
[9] vctrs_0.6.5 ravemanager_1.0.39 lifecycle_1.0.4 rlang_1.1.3
[13] pak_0.7.1
#> getOption("repos")
raveieeg CRAN
“https://rave-ieeg.r-universe.dev/” “https://cloud.r-project.org/”
#> Sys.getenv("tar")
[1] ""
#> system2(Sys.getenv("TAR"), "--version")
bsdtar 3.5.3 - libarchive 3.5.3 zlib/1.2.12 liblzma/5.0.5 bz2lib/1.0.8
#> Sys.getenv("PATH")
[1] "/Users/klab/miniconda3/bin:/Users/klab/miniconda3/condabin:/Users/klab/bin:/usr/local/bin:/usr/local/fsl/bin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security-crypted/codex.system/bootstrap/usr/local /bin:/var/run/com.apple.security.crypted/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.crypted/codex.system/bootstrap/usr/appleinternal/bin:/opt/X11/bin"
DESCRIPTION
was empty, but the packages affected were: targets
, raveio
, threeBrain
I don't really know how exactly conda could cause this, but nevertheless it is best to deactivate conda when you are installing R packages, probably even when you are just using (non-conda) R.
That's a good idea. Thanks for the advice. I'll deactivating conda.
Let me know if this worked.
Dear
pak
devs,I'm seeking for help (hint or advice). It's very rare, but I have encountered three times that installing a package leave files empty randomly. Basically all files are present, but some files have zero bytes after installation (they shouldn't). The problem with this issue is it's very hard to debug, especially as a package maintainer. The easiest solution is to reinstall all packages, which could be very frustrating and wasting of time.
I wonder do you have any clues why this could happen (or it may come from)? I'm trying to reproduce this issue.
From these three times, two came from Mac Pro 2019, Intel chip, and one from M2 ARM. Both are the latest OSX and R 4.3.2. Not sure if other OS has similar issues. The packages are installed in user directory.
Most packages having this issue came from
r-universe
(some CRAN packages also got zero-byte files), but I'm not sure about the causality.