Make torch installation robust to install_torch() exit-time segfault

[AntoineSoetewey]

Follow-up to #393 and to the segfault @mpadge reported in ropensci/software-review#784: on the rOpenSci build server, RUN Rscript -e 'torch::install_torch()' dies with a segfault, apparently after the installation itself completes ("failed somewhere in the cleanup process"). When that happens during docker build, the RUN step returns 139 and the layer -- including the completed installation -- is discarded, so the weekly server rebuild loses torch entirely.

Notably, this repo's own docker.yaml CI has built the identical Dockerfile successfully three times since #393 (runs 29487664312, 29712935423, 30232503908), with install_torch() executing in ~10 s and exiting 0. We also could not reproduce the crash in a four-variant docker build bisection from eddelbuettel/r2u:24.04 (runs + logs, details). The crash appears specific to the server environment; we are pursuing the root cause separately (a never-failing diagnostic build for the affected host is ready, and we will report upstream to mlverse/torch once a backtrace exists).

This PR makes the image build robust to it regardless of cause:

1. || echo ... on the install step -- an exit-time segfault no longer fails the build, so an installation that completed before the crash is kept in the layer instead of thrown away. On hosts where the step is healthy (like CI here) nothing changes.
2. A torch::install_torch_sitrep() layer -- the build log always records whether libtorch/lantern actually landed, so a broken torch state is visible instead of silent.
3. ENV TORCH_INSTALL "1" -- the mechanism @mpadge already used as a manual patch on the server, now permanent as a last-resort fallback: if the files really are missing at check time, torch installs itself on first load rather than hard-failing the checked package.

Alternative considered: dropping the RUN step and relying on TORCH_INSTALL=1 alone (the manual patch). That works, but moves the 170 MB libtorch download from image-build time to first use inside review containers; keeping the baked install as the primary path avoids that, with the envvar as safety net.

(ENV key value legacy form kept for consistency with the rest of the file, e.g. ENV ARROW_S3 "ON".)

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR hardens the Docker image build against an observed torch::install_torch() exit-time segfault (exit 139) on the rOpenSci build server so that a completed LibTorch install is retained in the Docker layer and torch availability is visible in build logs, with a runtime fallback if files are missing.

Changes:

• Makes the torch::install_torch() build step non-fatal (currently for any non-zero exit) to avoid discarding a successful install due to an exit-time crash.
• Adds a torch::install_torch_sitrep() step to record the installed state in build logs.
• Sets ENV TORCH_INSTALL "1" to allow torch to self-install on first load as a last-resort fallback.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mpadge]

Thanks for the attempts here! I'm going to close this PR because it is too Claude-verbose. The problem appears to be that torch_install() still does not install all needed tools. Even after that line, library(torch) immediately issues an interactive prompt to download additional software:

trying URL 'https://download.pytorch.org/libtorch/cpu/libtorch-shared-with-deps-2.8.0%2Bcpu.zip'
Content type 'unknown' length 178902575 bytes (170.6 MB)
==================================================
downloaded 170.6 MB

trying URL 'https://torch-cdn.mlverse.org/binaries/refs/heads/cran/v0.17.0/latest/lantern-0.17.0+cpu+x86_64-Linux.zip'
Content type 'application/zip' length 5996754 bytes (5.7 MB)
==================================================
downloaded 5.7 MB

With those two additional packages, everything is then fine, and checks run perfectly. So we just need to skip what seems in current form to be a hard-coded interactive step after initial install_torch(). And that is exactly what the envvar does, so I'll update to just add that single line. Thanks!

(And just speculating here, but those downloads are clearly in response to hardware probing, which suggests to me that install_torch() maybe stops before hardware probes, and relies on the envvar to auto-proceed beyond that?)