pak icon indicating copy to clipboard operation
pak copied to clipboard

pkg_install() does not install new version, but no indication of error

Open ijlyttle opened this issue 1 year ago • 4 comments

This may be related to #390.

Apologies in advance as this behavior occurs only on a self-hosted runner used on my company's GitHub enterprise - it does not happen on my local computer or on public GitHub runners.

In essence, my runner's pak cache has the CRAN version of reticulate v1.25, and I want to install a forked branch with version 1.25-9001.

I run (using actions):

  result <- pak::pkg_install("ijlyttle/reticulate@check-config") # 1.25-9001
  print(str(result))

There is no apparent bad news from running pak::pkg_install(); part of the result data frame has:

 $ cache_status    : chr  NA NA NA NA ...
 $ lib_status      : chr  "no-update" "current" "current" "current" ...
 $ old_version     : Named chr  "1.25" "1.0.1" "1.8.0" "0.1-7" ...
  ..- attr(*, "names")= chr [1:11] "reticulate" "here" "jsonlite" "png" ...
 $ new_version     : chr  "1.25-9001" NA NA NA ...
 $ fulltarget      : chr  "/tmp/RtmpHlOFJg/file4472f760b816a/src/contrib/reticulate_1.25.tar.gz" "/tmp/RtmpHlOFJg/file4472f760b816a/src/contrib/here_1.0.1.tar.gz" "/tmp/RtmpHlOFJg/file4472f760b816a/src/contrib/jsonlite_1.8.0.tar.gz" "/tmp/RtmpHlOFJg/file4472f760b816a/src/contrib/png_0.1-7.tar.gz" ...
 $ fulltarget_tree : chr  "/tmp/RtmpHlOFJg/file4472f760b816a/src/contrib/reticulate_1.25.tar.gz-t" "/tmp/RtmpHlOFJg/file4472f760b816a/src/contrib/here_1.0.1.tar.gz-t" "/tmp/RtmpHlOFJg/file4472f760b816a/src/contrib/jsonlite_1.8.0.tar.gz-t" "/tmp/RtmpHlOFJg/file4472f760b816a/src/contrib/png_0.1-7.tar.gz-t" ...
 $ download_status : chr  "Had" "Had" "Had" "Had" ...
 $ download_error  :List of 11
  ..$ : NULL
  ..$ : NULL
  ..$ : NULL
  ..$ : NULL
  ..$ : NULL
  ..$ : NULL
  ..$ : NULL
  ..$ : NULL
  ..$ : NULL
  ..$ : NULL
  ..$ : NULL

Then I run:

  packageVersion("reticulate")

the result is

[1] ‘1.25’

But I was expecting [1] ‘1.25-9001’.

If I modify the action to include a pak::cache_clean(), then it works as I expect.

Are there any options or environment variables (or even other diagnostic steps) I can try to help see what's going on?

Thanks!

ijlyttle avatar Aug 23 '22 00:08 ijlyttle

I can't reproduce it, can you show the workflow that has this problem?

gaborcsardi avatar Aug 23 '22 06:08 gaborcsardi

Hi @gaborcsardi, I have a public remote of the branch - here's the (self-hosted) workflow file - my apologies - it's a mess as I was just "trying stuff" at the time.

Here's the file of where I delete the cache and pak installs correctly (I am still wrestling with reticulate).

Part of the issue might be that this runner persists stuff between runs - I need to talk more with "my folks" to get details. I am more accustomed to the public GH runners that we use, where everything starts new each time.

Thanks!

ijlyttle avatar Aug 23 '22 11:08 ijlyttle

Hmmm, if the library is cached, then this could be because of https://github.com/r-lib/pkgdepends/blob/main/R/type-github.R#L168-L172 which will not update a locally installed package.

This is not great, and we should still update a package if the GH package is newer, so I'll update it.

gaborcsardi avatar Aug 23 '22 12:08 gaborcsardi

will not update a locally installed package.

Although it should still update it if it is not a dependency.... so I still reproduce this...

gaborcsardi avatar Aug 23 '22 12:08 gaborcsardi