pak lockfile creation within github action hangs forever

I am using 'r-lib/actions/setup-r-dependencies@v2' within another action and it starts fine but for some reason it hangs when pak is creating the lock file forever, meaning 2+h , without error. (In the same repo in the rcmdcheck action the lockfile creation takes ~10s with no issues). Here is an example run.

Maybe someone here has an idea or tips how to troubleshoot issues like this on gha.

This is the gha log until it hangs:

  * installing *binary* package ‘pak’ ...
  * DONE (pak)
  
  The downloaded source packages are in
  	‘/tmp/RtmpSGKnxU/downloaded_packages’
Dependency resolution
  ℹ Creating lockfile '.github/pkg.lock'
  
  ✔ Updated metadata database: 3.10 MB in 7 files.
  
  ℹ Creating lockfile '.github/pkg.lock'
  ℹ Updating metadata database
  ✔ Updating metadata database ... done

Can you show an example where this happened?

The example run I started when creating the post actually finished after 2.5h:
✔ Created lockfile '.github/pkg.lock' [2h 36m 31.3s]

Here a run using the setup-r-dependecies action in the same repo working as expected (~10s):

When I run

pak::lockfile_create( 
                c("deps::.", "any::sessioninfo", "github::lorenzwalthert/touchstone@main", "ggplot2", "dplyr", "gert"), 
                lockfile = ".github/pkg.lock", 
                dependencies = c("all") 
              )    

on my local linux machine with the same R & pak version on the same branch, the lock file is created within 10s as expected.

Thanks for your support!

The master branch of r-lib/actions is not updated, please use the v2 tag instead. See GitHub - r-lib/actions: GitHub Actions for the R community

Also, consider using any:: for the extra packages that you install: actions/setup-r-dependencies at v2-branch · r-lib/actions · GitHub

Never mind, I see that you are using v2: touchstone/action.yaml at 4af8fa6bd038b4a6413689022645b018595e7dc7 · lorenzwalthert/touchstone · GitHub

Do you set up any extra repositories?

The action allows for setting up extra repositories but this step is after setup-r-dependencies (e.g. {styler} uses {here}) and in this run specifically there are no extra repositories used.
I updated the {touchstone} action with any:: as you suggested and will test with that.

I can reproduce this if I use the RSPM repo focal/291: simstudy/config.json at c6c62e9331a4bb3ce934e6a7f28918cabb9514cb · assignUser/simstudy · GitHub

I am not sure why you need that but if it is for reproducibility, that is not working very well, because some dependencies are coming from CRAN anyway, see the lock file.

Unfortunately the pak dependency solver is not great if you have multiple candidates for most of the packages, hence the long running time. If you use the latest RSPM, then it should be fast.

Hm I see, with any::: it works quicker (but still slow ~4min), yes it is intended for reproducibiloty, prior to switching to setup-r-dependencies we used {remotes} would that have the same issues with reproducibility?

Ok i tested it with a current RSPM:Update config.json · assignUser/simstudy@976ac4d · GitHub
and it works as expected, sorry for the goose chase. I did not know the RSPM link was so old :confused:

Thank you for your work on pak, it is a great package and on windows it is a god send :smiley:

If you use any:: that is better in general, because then pak does not try to install the latest version of these extra packages, and their soft dependencies also won't be installed.

Unfortunately you cannot specify this for lorenzwalthert/touchstone so all dependencies of this package will be installed, and it requires some packages, e.g. testthat 3.0.0, that are not available in the RSPM repo.

If you look at the lock file, you'll see that some packages are coming from CRAN, still.

A better option for now, until you can tell pak not to install the soft dependencies of the extra GH package, is to remove lorenzwalthert/touchstone from the extra packages, and install it manually, after the setup-r-dependencies step, by calling

pak::pkg_install("lorenzwalthert/touchstone@main")

I think remotes will just use install.packages() for the dependencies, which always chooses the newest version, so more packages will come from CRAN.

Thanks again for your in-depth help! I changed the action accordingly :slight_smile:

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.