ku-awdc / runjags

An R package implementing interface utilities, model templates, parallel computing methods and additional distributions for MCMC models in JAGS
GNU General Public License v2.0
4 stars 2 forks source link

Crash on macOS if jags was installed via Homebrew #2

Open RLumSK opened 1 year ago

RLumSK commented 1 year ago

Background

I am using 'runjags' within an R package called 'BayLum' to which I contribute from to time code. All worked fine, but I've been struggling with an odd error message of 'runjags' that only seems to show on the CI platform using GitHub actions for macOS-12. Neither it showed locally nor flagged on the CRAN server farms.

Error message

In the tests, 'runjags' simply stops with the message

Error in if (j_type == "x86_64 arm64") j_type <- "universal": argument is of length zero

Cause

I finally figured out that this message is only shown in combination with Homebrew on macOS. Somehow the constructed path to the binaries, which should include Cellar, is not correct and hence (as an example)

j_type <- system("lipo -archs /usr/local/jags/4.3.1/libexec/jags-terminal", intern = TRUE)

leads to

j_type
character(0)
attr(,"status")
[1] 1

Since j_type is character(0) the error is shown in the if condition.

Potential solution

If I am not mistaken, line 126 in utilities.R:

paths <- c(from.variable, "jags", "/opt/local/bin/jags", "/opt/local/sbin/jags", "/usr/texbin/jags", "/usr/bin/jags", "/bin/jags", "/usr/sbin/jags", "/sbin/jags", "/usr/local/bin/jags", "/opt/R/arm64/bin/jags", "/usr/X11/bin/jags")

needs to be enhanced as follows:

paths <- c(from.variable, "jags", "/opt/local/bin/jags", "/opt/local/sbin/jags", "/usr/texbin/jags", "/usr/bin/jags", "/bin/jags", "/usr/sbin/jags", "/sbin/jags", "/usr/local/bin/jags", "/opt/R/arm64/bin/jags", "/usr/X11/bin/jags", "/usr/local/Cellar/jags")
juniperlsimonis commented 1 year ago

I just ran into this issue myself, and have been trying to figure out a short-term workaround in GHA

I'm not a mac user at all, so only have dealt with this on GHA, and have no way of reproducing it locally, but have been working on a min example in this repo: https://github.com/dapperstats/ghatests I haven't gotten it all working yet, tho.

there is a similar issue that was addressed in rjags https://gist.github.com/casallas/8411082 (it is not the same exact issue, but associated with location of the files)

something to note is the the /Cellar/ part of the path is included, but there are also shortcuts available, including /usr/local/bin/jags. see https://mkyong.com/mac/where-does-homebrew-install-packages-on-mac/

however, runjags::testjags() assumes that local/bin/ on a mac should be swapped into local/libexec/jags-terminal/, but there's no shortcut there.

a further aspect to this issue that is confusing/challenging is that both runjags::findjags() and runjags::runjags.getOption("jagspath") can find the proper path, /usr/local/bin/jags, but runjags::testjags() cannot. the line you posted to in utilities is actually within findjags() so I don't think that would fix the issue. (again: big caveats on not knowing for sure given lack of reproducible example)

I think the line that needs to get updated is this one, as that's where that path gets gsubbed to a non-working one https://github.com/ku-awdc/runjags/blob/6efdf519a22971fd4941b150fc2b884145a24bf9/R/utilities.R#L558. But again, without the capacity to set up a repro example locally, I'm kinda grasping a bit at straws

juniperlsimonis commented 1 year ago

I've found a successful-on-GHA workaround by downloading and installing the .pkg file using sudo curl and sudo installer:

      - name: Install system dependencies on MacOS
        if: runner.os == 'macOS'
        run: |
          sudo curl --location https://sourceforge.net/projects/mcmc-jags/files/JAGS/4.x/Mac%20OS%20X/JAGS-4.3.1.pkg -o /usr/local/JAGS-4.3.1.pkg
          sudo installer -pkg /usr/local/JAGS-4.3.1.pkg -target /usr/local/bin/
RLumSK commented 1 year ago

@juniperlsimonis Thank you for looking into it and for the explanations. You are probably right about the different line in the code that needs to be fixed. Also, thank you for your workaround, though I have not yet adapted my GitHub actions because I still hope the underlying reason can be treated.