From 809be4432c8ac776d171fac9b94a53db4937a988 Mon Sep 17 00:00:00 2001
From: duan_j <jiaxin.duan@psi.ch>
Date: Tue, 18 Aug 2026 19:23:19 +0200
Subject: [PATCH 1/8] added readme

---
 ccp4/README.md | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 ccp4/README.md

diff --git a/ccp4/README.md b/ccp4/README.md
new file mode 100644
index 0000000..e69de29

From 273569c87e7bba02183f36c382d387f27c86e849 Mon Sep 17 00:00:00 2001
From: Dawn <jiaxin.duan@psi.ch>
Date: Tue, 18 Aug 2026 19:44:06 +0200
Subject: [PATCH 2/8] Add ccp4 module: vendor tarball, non-interactive
 BINARY.setup

Pre-agrees the CCP4 licence via .agree2ccp4v6 so BINARY.setup never
prompts. Download via urls: with unpacker: none (untar once into PREFIX,
BINARY.setup patches paths at final location). Build tmp and download
cache go to /das/work/p21/p21515/.cache/Pmodules through
~/.Pmodules/Pmodules.yaml (see README) since /var/tmp and the home quota
are too small for the ~5 GB tarball.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 ccp4/README.md         | 53 ++++++++++++++++++++++++++++++++++++++++++
 ccp4/build             | 27 +++++++++++++++++++++
 ccp4/files/config.yaml | 19 +++++++++++++++
 ccp4/modulefile        | 19 +++++++++++++++
 4 files changed, 118 insertions(+)
 create mode 100755 ccp4/build
 create mode 100644 ccp4/files/config.yaml
 create mode 100644 ccp4/modulefile

diff --git a/ccp4/README.md b/ccp4/README.md
index e69de29..7baa009 100644
--- a/ccp4/README.md
+++ b/ccp4/README.md
@@ -0,0 +1,53 @@
+# ccp4
+
+CCP4 suite (binary distribution, bundled with SHELX and ARP/wARP) for
+macromolecular crystallography. https://www.ccp4.ac.uk/
+
+- Vendor tarball install: default `prep` downloads the ~5 GB tarball
+  (cached in `$PMODULES_DISTFILESDIR`), `install` untars it into `$PREFIX`
+  and runs `BINARY.setup`.
+- Non-interactive: the CCP4 licence is pre-agreed via `.agree2ccp4v6`
+  before `BINARY.setup` runs, so the build never prompts.
+- No `shasums:`: the download link is session-gated (`sid=` expires), so
+  the checksum cannot be pinned ahead of the first fetch. After the first
+  successful build, `sha256sum` the cached tarball and add it if wanted.
+- Module version is the series (`9.0`); minor updates (9.0.xxx) come via
+  the CCP4 update manager inside the installation.
+
+## Build on Ra
+
+One-time per user: put the Pmodules build tmp and download cache on
+/das instead of /var/tmp and $HOME (the tarball alone would blow the
+home quota):
+
+```bash
+mkdir -p /das/work/p21/p21515/.cache/Pmodules/distfiles ~/.Pmodules
+cat > ~/.Pmodules/Pmodules.yaml <<'EOF'
+tmp_dir: /das/work/p21/p21515/.cache/Pmodules
+download_dir: /das/work/p21/p21515/.cache/Pmodules/distfiles
+EOF
+```
+
+Then:
+
+```bash
+module use unstable && module load modbuild/2.1.2
+cd ccp4
+modbuild build --check-mode 9.0     # yamllint the config first
+modbuild build 9.0
+```
+
+If the download fails (expired sid), fetch a fresh link from
+https://www.ccp4.ac.uk/download/ and update `files/config.yaml`, or drop a
+hand-downloaded tarball into the distfiles dir under the `name:` given in
+`files/config.yaml`.
+
+## Verify
+
+```bash
+module use MX unstable && module load ccp4/9.0
+which refmac5 ccp4i2
+echo $CCP4          # should point into /opt/psi/MX/ccp4/9.0/ccp4
+```
+
+Bundled SHELX and ARP/wARP still need their own academic registrations.
diff --git a/ccp4/build b/ccp4/build
new file mode 100755
index 0000000..f82090b
--- /dev/null
+++ b/ccp4/build
@@ -0,0 +1,27 @@
+#!/usr/bin/env modbuild
+
+# Download happens in the default prep via urls: in files/config.yaml.
+# unpacker: none because BINARY.setup patches paths relative to its final
+# location — we untar once, directly into $PREFIX, instead of unpacking
+# ~20 GB into the build tmp and copying it over.
+
+pbuild::configure() {
+    :
+}
+
+pbuild::compile() {
+    :
+}
+
+pbuild::install() {
+    cd "${PREFIX}"
+    tar -xzf "${SRC_DIR}/ccp4-${V}-shelx-arp-x86_64.tar.gz"
+    # Pre-agree the CCP4 licence so BINARY.setup skips its interactive prompt
+    # (downloading from ccp4.ac.uk already required accepting it). The printf
+    # answers any prompt a newer BINARY.setup might still ask; printf instead
+    # of `yes` because modbuild runs with pipefail and yes dies by SIGPIPE.
+    touch "${PREFIX}/.agree2ccp4v6" "${HOME}/.agree2ccp4v6"
+    printf 'y\ny\ny\n' | "./ccp4-${V_MAJOR}.${V_MINOR}/BINARY.setup"
+    # version-independent symlink so the modulefile survives 9.0.xxx updates
+    ln -sfn "ccp4-${V_MAJOR}.${V_MINOR}" ccp4
+}
diff --git a/ccp4/files/config.yaml b/ccp4/files/config.yaml
new file mode 100644
index 0000000..c2af7de
--- /dev/null
+++ b/ccp4/files/config.yaml
@@ -0,0 +1,19 @@
+---
+format: 1
+ccp4:
+  defaults:
+    group: MX
+    overlay: base
+    relstage: unstable
+    urls:
+      # sid= is session-generated on ccp4.ac.uk and expires; if the download
+      # fails, get a fresh link from https://www.ccp4.ac.uk/download/
+      # (package "CCP4 + SHELX + ARP/wARP", Linux x86_64) or pre-stage the
+      # tarball as $PMODULES_DISTFILESDIR/ccp4-<version>-shelx-arp-x86_64.tar.gz
+      - url: "https://www.ccp4.ac.uk/download/download_file.php?os=linux&pkg=ccp4-shelx-arp-x86_64&sid=09b78d1369f605f517efa393f88d2bae713ad0b6"
+        name: ccp4-${V}-shelx-arp-x86_64.tar.gz
+        unpacker: none
+  versions:
+    9.0:
+      config:
+        relstage: unstable
diff --git a/ccp4/modulefile b/ccp4/modulefile
new file mode 100644
index 0000000..4984cdc
--- /dev/null
+++ b/ccp4/modulefile
@@ -0,0 +1,19 @@
+#%Module1.0
+
+module-whatis       "CCP4: software suite for macromolecular X-ray crystallography"
+module-url          "https://www.ccp4.ac.uk/"
+module-license      "CCP4 licence; bundled SHELX and ARP/wARP need their own academic registration"
+module-maintainer   "Jiaxin Duan <jiaxin.duan@psi.ch>"
+
+module-help "
+CCP4 suite (binary distribution bundled with SHELX and ARP/wARP) for
+macromolecular crystallography: data processing, phasing, model building
+and refinement (refmac5, ccp4i2, coot, shelx, arp/warp, ...).
+
+Loading this module sources ccp4.setup-sh, which sets CCP4, CBIN,
+CCP4_SCR and PATH.
+"
+
+# build's install() leaves a version-independent 'ccp4' symlink next to
+# ccp4-<major.minor>, so this line survives 9.0.xxx updates
+puts stdout "source $PREFIX/ccp4/bin/ccp4.setup-sh;"

From 8f1b3bf3a195851f82003b760a7ff8fb995354c7 Mon Sep 17 00:00:00 2001
From: Dawn <jiaxin.duan@psi.ch>
Date: Tue, 18 Aug 2026 19:58:07 +0200
Subject: [PATCH 3/8] ccp4 README: fix modbuild flags per 2.1.3 --help

No --check-mode exists; --prep is the real way to pre-fetch and check the
tmp_dir config. modbuild on Ra is 2.1.3 now.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 ccp4/README.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ccp4/README.md b/ccp4/README.md
index 7baa009..a7ca21a 100644
--- a/ccp4/README.md
+++ b/ccp4/README.md
@@ -31,9 +31,9 @@ EOF
 Then:
 
 ```bash
-module use unstable && module load modbuild/2.1.2
+module use unstable && module load modbuild/2.1.3
 cd ccp4
-modbuild build --check-mode 9.0     # yamllint the config first
+modbuild build --prep 9.0   # download/cache only; also verifies tmp_dir took effect
 modbuild build 9.0
 ```
 

From 3bf22a4b7e8db75d153988128392e3e2fdf386ec Mon Sep 17 00:00:00 2001
From: Dawn <jiaxin.duan@psi.ch>
Date: Tue, 18 Aug 2026 20:07:19 +0200
Subject: [PATCH 4/8] ccp4: die-guard install steps, glob ccp4-* top dir

First Ra run "succeeded" while broken: modbuild has no errexit in hooks,
so a truncated cached tarball (gzip EOF) and a wrong hardcoded top dir
(tarball unpacks to ccp4-9, not ccp4-9.0) scrolled by and the modulefile
got installed anyway. Every critical step now ends the build via
std::die, the top dir is globbed, and install verifies ccp4.setup-sh
exists before finishing. README documents the recovery (rm partial
tarball from distfiles, --clean-install).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 ccp4/README.md | 20 +++++++++++++++++++-
 ccp4/build     | 20 ++++++++++++++++----
 2 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/ccp4/README.md b/ccp4/README.md
index a7ca21a..2a5027f 100644
--- a/ccp4/README.md
+++ b/ccp4/README.md
@@ -42,12 +42,30 @@ https://www.ccp4.ac.uk/download/ and update `files/config.yaml`, or drop a
 hand-downloaded tarball into the distfiles dir under the `name:` given in
 `files/config.yaml`.
 
+## Known failure modes
+
+- **"done" but broken install**: modbuild has no errexit in hooks — errors in
+  `pbuild::install` used to scroll by and the build still reported done. The
+  build script now `std::die`s on every critical step.
+- **Truncated download reused silently**: an interrupted `curl` leaves a
+  partial file in the distfiles dir, and prep reuses any file it finds there
+  (no integrity check without `shasums:`). Symptom:
+  `gzip: stdin: unexpected end of file`. Fix:
+  ```bash
+  rm ~/.cache/Pmodules/distfiles/ccp4-9.0-shelx-arp-x86_64.tar.gz
+  modbuild build --clean-install 9.0
+  # or verify by hand before building:
+  gzip -t ~/.cache/Pmodules/distfiles/ccp4-9.0-shelx-arp-x86_64.tar.gz
+  ```
+- The tarball unpacks to `ccp4-9` (not `ccp4-9.0` as the CCP4 install doc
+  implies); the build globs `ccp4-*/` instead of assuming the name.
+
 ## Verify
 
 ```bash
 module use MX unstable && module load ccp4/9.0
 which refmac5 ccp4i2
-echo $CCP4          # should point into /opt/psi/MX/ccp4/9.0/ccp4
+echo $CCP4          # should point into /opt/psi/MX/ccp4/9.0/ccp4 (-> ccp4-9)
 ```
 
 Bundled SHELX and ARP/wARP still need their own academic registrations.
diff --git a/ccp4/build b/ccp4/build
index f82090b..faaf73e 100755
--- a/ccp4/build
+++ b/ccp4/build
@@ -15,13 +15,25 @@ pbuild::compile() {
 
 pbuild::install() {
     cd "${PREFIX}"
-    tar -xzf "${SRC_DIR}/ccp4-${V}-shelx-arp-x86_64.tar.gz"
+    # modbuild has no errexit in hooks — without the die-guards a failed step
+    # still ends in a "done" build with a broken PREFIX (happened 2026-08-18
+    # with a truncated cached tarball).
+    tar -xzf "${SRC_DIR}/ccp4-${V}-shelx-arp-x86_64.tar.gz" || \
+        std::die 42 "ccp4: untar failed — cached tarball likely truncated; rm it from the distfiles dir and re-run (fetch a fresh sid link if the download fails)"
+    # the 9-series tarball unpacks to ccp4-9 (NOT ccp4-9.0 as the install doc
+    # implies) — glob instead of guessing the name
+    local -a top=( ccp4-*/ )
+    [[ -x "${top[0]}BINARY.setup" ]] || \
+        std::die 42 "ccp4: ${top[0]}BINARY.setup not found — vendor layout changed, inspect ${PREFIX}"
     # Pre-agree the CCP4 licence so BINARY.setup skips its interactive prompt
     # (downloading from ccp4.ac.uk already required accepting it). The printf
     # answers any prompt a newer BINARY.setup might still ask; printf instead
     # of `yes` because modbuild runs with pipefail and yes dies by SIGPIPE.
     touch "${PREFIX}/.agree2ccp4v6" "${HOME}/.agree2ccp4v6"
-    printf 'y\ny\ny\n' | "./ccp4-${V_MAJOR}.${V_MINOR}/BINARY.setup"
-    # version-independent symlink so the modulefile survives 9.0.xxx updates
-    ln -sfn "ccp4-${V_MAJOR}.${V_MINOR}" ccp4
+    printf 'y\ny\ny\n' | "./${top[0]}BINARY.setup" || \
+        std::die 42 "ccp4: BINARY.setup failed"
+    # version-independent symlink so the modulefile survives 9.x updates
+    ln -sfn "${top[0]%/}" ccp4
+    [[ -r ccp4/bin/ccp4.setup-sh ]] || \
+        std::die 42 "ccp4: ccp4/bin/ccp4.setup-sh missing after setup — the modulefile would be broken"
 }

From 1332910115b63708df74b396b11eb5e273684452 Mon Sep 17 00:00:00 2001
From: Dawn <jiaxin.duan@psi.ch>
Date: Tue, 18 Aug 2026 20:14:26 +0200
Subject: [PATCH 5/8] ccp4: download via wget --continue in custom prep

Builtin curl in default prep has no retry/resume: an interrupted 3.7 GB
download restarts from zero and leaves a partial file that prep reuses
silently. Custom pbuild::prep resumes with wget --continue and gates the
build on gzip -t, so a truncated tarball can neither be reused nor
require a full re-download. urls: dropped from config.yaml (unused with
custom prep); install untars straight from the distfiles cache instead
of a pointless 3.7 GB copy via SRC_DIR.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 ccp4/README.md         | 23 ++++++++++-------------
 ccp4/build             | 30 ++++++++++++++++++++++++------
 ccp4/files/config.yaml | 11 +++--------
 3 files changed, 37 insertions(+), 27 deletions(-)

diff --git a/ccp4/README.md b/ccp4/README.md
index 2a5027f..2887e3e 100644
--- a/ccp4/README.md
+++ b/ccp4/README.md
@@ -3,9 +3,10 @@
 CCP4 suite (binary distribution, bundled with SHELX and ARP/wARP) for
 macromolecular crystallography. https://www.ccp4.ac.uk/
 
-- Vendor tarball install: default `prep` downloads the ~5 GB tarball
-  (cached in `$PMODULES_DISTFILESDIR`), `install` untars it into `$PREFIX`
-  and runs `BINARY.setup`.
+- Vendor tarball install: custom `prep` downloads the ~3.7 GB tarball with
+  `wget --continue` (resumes partial downloads; the builtin curl can't) and
+  verifies it with `gzip -t`; `install` untars it into `$PREFIX` and runs
+  `BINARY.setup`.
 - Non-interactive: the CCP4 licence is pre-agreed via `.agree2ccp4v6`
   before `BINARY.setup` runs, so the build never prompts.
 - No `shasums:`: the download link is session-gated (`sid=` expires), so
@@ -47,16 +48,12 @@ hand-downloaded tarball into the distfiles dir under the `name:` given in
 - **"done" but broken install**: modbuild has no errexit in hooks — errors in
   `pbuild::install` used to scroll by and the build still reported done. The
   build script now `std::die`s on every critical step.
-- **Truncated download reused silently**: an interrupted `curl` leaves a
-  partial file in the distfiles dir, and prep reuses any file it finds there
-  (no integrity check without `shasums:`). Symptom:
-  `gzip: stdin: unexpected end of file`. Fix:
-  ```bash
-  rm ~/.cache/Pmodules/distfiles/ccp4-9.0-shelx-arp-x86_64.tar.gz
-  modbuild build --clean-install 9.0
-  # or verify by hand before building:
-  gzip -t ~/.cache/Pmodules/distfiles/ccp4-9.0-shelx-arp-x86_64.tar.gz
-  ```
+- **Interrupted download**: prep now detects a truncated tarball with
+  `gzip -t` and resumes it with `wget --continue` — just re-run
+  `modbuild build 9.0`. A download that dies with
+  `Failure writing output to destination` means quota/disk full at the
+  distfiles dir, not a network problem — free space or move `download_dir:`
+  (see above) before retrying.
 - The tarball unpacks to `ccp4-9` (not `ccp4-9.0` as the CCP4 install doc
   implies); the build globs `ccp4-*/` instead of assuming the name.
 
diff --git a/ccp4/build b/ccp4/build
index faaf73e..011b0c1 100755
--- a/ccp4/build
+++ b/ccp4/build
@@ -1,9 +1,25 @@
 #!/usr/bin/env modbuild
 
-# Download happens in the default prep via urls: in files/config.yaml.
-# unpacker: none because BINARY.setup patches paths relative to its final
-# location — we untar once, directly into $PREFIX, instead of unpacking
-# ~20 GB into the build tmp and copying it over.
+# Custom prep instead of urls: in config.yaml — modbuild's builtin curl has
+# no retry/resume, so an interrupted 3.7 GB download restarts from zero and
+# leaves a partial file the next prep reuses silently. wget --continue
+# resumes it, and gzip -t gates the build on an intact tarball.
+# sid= in the URL is session-generated on ccp4.ac.uk and expires; on download
+# failure get a fresh link from https://www.ccp4.ac.uk/download/ (package
+# "CCP4 + SHELX + ARP/wARP", Linux x86_64), or pre-stage the tarball by hand
+# in $PMODULES_DISTFILESDIR under the name below.
+pbuild::prep() {
+    local -r tarball="${PMODULES_DISTFILESDIR}/ccp4-${V}-shelx-arp-x86_64.tar.gz"
+    local -r url='https://www.ccp4.ac.uk/download/download_file.php?os=linux&pkg=ccp4-shelx-arp-x86_64&sid=09b78d1369f605f517efa393f88d2bae713ad0b6'
+    if ! gzip -t "${tarball}" 2>/dev/null; then
+        mkdir -p "${PMODULES_DISTFILESDIR}"
+        wget --continue --tries=20 --waitretry=30 \
+             --output-document="${tarball}" "${url}" || \
+            std::die 42 "ccp4: download failed — quota/disk full, or expired sid (fetch a fresh link from https://www.ccp4.ac.uk/download/)"
+        gzip -t "${tarball}" || \
+            std::die 42 "ccp4: tarball fails gzip -t after download — re-run to resume, or rm it to restart"
+    fi
+}
 
 pbuild::configure() {
     :
@@ -18,8 +34,10 @@ pbuild::install() {
     # modbuild has no errexit in hooks — without the die-guards a failed step
     # still ends in a "done" build with a broken PREFIX (happened 2026-08-18
     # with a truncated cached tarball).
-    tar -xzf "${SRC_DIR}/ccp4-${V}-shelx-arp-x86_64.tar.gz" || \
-        std::die 42 "ccp4: untar failed — cached tarball likely truncated; rm it from the distfiles dir and re-run (fetch a fresh sid link if the download fails)"
+    # untar straight from the distfiles cache — no point copying 3.7 GB into
+    # SRC_DIR first (prep already verified it with gzip -t)
+    tar -xzf "${PMODULES_DISTFILESDIR}/ccp4-${V}-shelx-arp-x86_64.tar.gz" || \
+        std::die 42 "ccp4: untar failed — rm the tarball from the distfiles dir and re-run"
     # the 9-series tarball unpacks to ccp4-9 (NOT ccp4-9.0 as the install doc
     # implies) — glob instead of guessing the name
     local -a top=( ccp4-*/ )
diff --git a/ccp4/files/config.yaml b/ccp4/files/config.yaml
index c2af7de..0c88ce7 100644
--- a/ccp4/files/config.yaml
+++ b/ccp4/files/config.yaml
@@ -5,14 +5,9 @@ ccp4:
     group: MX
     overlay: base
     relstage: unstable
-    urls:
-      # sid= is session-generated on ccp4.ac.uk and expires; if the download
-      # fails, get a fresh link from https://www.ccp4.ac.uk/download/
-      # (package "CCP4 + SHELX + ARP/wARP", Linux x86_64) or pre-stage the
-      # tarball as $PMODULES_DISTFILESDIR/ccp4-<version>-shelx-arp-x86_64.tar.gz
-      - url: "https://www.ccp4.ac.uk/download/download_file.php?os=linux&pkg=ccp4-shelx-arp-x86_64&sid=09b78d1369f605f517efa393f88d2bae713ad0b6"
-        name: ccp4-${V}-shelx-arp-x86_64.tar.gz
-        unpacker: none
+    # no urls: — download lives in build's pbuild::prep (wget --continue +
+    # gzip -t), because the builtin curl has no retry/resume for the 3.7 GB
+    # session-gated tarball
   versions:
     9.0:
       config:

From 89a9c682fe03841d87bc3cec9cb6902609714085 Mon Sep 17 00:00:00 2001
From: Dawn <jiaxin.duan@psi.ch>
Date: Tue, 18 Aug 2026 20:27:34 +0200
Subject: [PATCH 6/8] ccp4 README: note that install is slow, not stuck

Untarring 3.7 GB into ~15-20 GB of small files on shared /opt/psi takes
10-30 min silently; documented so nobody kills a healthy build.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 ccp4/README.md | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/ccp4/README.md b/ccp4/README.md
index 2887e3e..9020c85 100644
--- a/ccp4/README.md
+++ b/ccp4/README.md
@@ -43,6 +43,20 @@ https://www.ccp4.ac.uk/download/ and update `files/config.yaml`, or drop a
 hand-downloaded tarball into the distfiles dir under the `name:` given in
 `files/config.yaml`.
 
+## Install is SLOW — not stuck
+
+The `install` step untars 3.7 GB into ~15-20 GB of small files on shared
+/opt/psi storage: the tar alone runs 10-30 min with no output (gzip is
+single-threaded, small-file creation on network storage is the
+bottleneck), and `BINARY.setup` afterwards walks the whole installation
+for several more minutes. Watch progress from a second shell:
+
+```bash
+watch -n 30 'du -sh /opt/psi/MX/ccp4/9.0/'
+```
+
+Growing `du` = working. Only investigate if it's frozen for 10+ min.
+
 ## Known failure modes
 
 - **"done" but broken install**: modbuild has no errexit in hooks — errors in

From fcedf651b615c4b0ad69bfedaa964209cb566ea6 Mon Sep 17 00:00:00 2001
From: Dawn <jiaxin.duan@psi.ch>
Date: Tue, 18 Aug 2026 20:37:55 +0200
Subject: [PATCH 7/8] ccp4 README: BINARY.setup py-compile phase is also slow

Byte-compiling the bundled Python env writes thousands of .pyc files on
network storage; whole install budget on Ra is about an hour.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 ccp4/README.md | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/ccp4/README.md b/ccp4/README.md
index 9020c85..d97a2cd 100644
--- a/ccp4/README.md
+++ b/ccp4/README.md
@@ -48,8 +48,11 @@ hand-downloaded tarball into the distfiles dir under the `name:` given in
 The `install` step untars 3.7 GB into ~15-20 GB of small files on shared
 /opt/psi storage: the tar alone runs 10-30 min with no output (gzip is
 single-threaded, small-file creation on network storage is the
-bottleneck), and `BINARY.setup` afterwards walks the whole installation
-for several more minutes. Watch progress from a second shell:
+bottleneck). `BINARY.setup` afterwards is just as bad — it walks the
+whole installation patching paths and then **byte-compiles the bundled
+Python environment** ("compiling py-files"), thousands of tiny .pyc
+writes on network storage; expect another 15-30+ min. Budget roughly an
+hour for the whole install on Ra. Watch progress from a second shell:
 
 ```bash
 watch -n 30 'du -sh /opt/psi/MX/ccp4/9.0/'

From c0e4e55fb9b2b38d4dbba787f5b70ddec6c59b17 Mon Sep 17 00:00:00 2001
From: Dawn <jiaxin.duan@psi.ch>
Date: Tue, 18 Aug 2026 20:45:49 +0200
Subject: [PATCH 8/8] ccp4 README: document explicit --tmpdir/--distdir build
 command

The ~/.Pmodules/Pmodules.yaml route did not reliably set download_dir,
so the maintained recipe now passes both dirs on the command line;
readers must adapt the p-group path to their own.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 ccp4/README.md | 44 ++++++++++++++++++++++++--------------------
 1 file changed, 24 insertions(+), 20 deletions(-)

diff --git a/ccp4/README.md b/ccp4/README.md
index d97a2cd..a110664 100644
--- a/ccp4/README.md
+++ b/ccp4/README.md
@@ -17,27 +17,31 @@ macromolecular crystallography. https://www.ccp4.ac.uk/
 
 ## Build on Ra
 
-One-time per user: put the Pmodules build tmp and download cache on
-/das instead of /var/tmp and $HOME (the tarball alone would blow the
-home quota):
-
-```bash
-mkdir -p /das/work/p21/p21515/.cache/Pmodules/distfiles ~/.Pmodules
-cat > ~/.Pmodules/Pmodules.yaml <<'EOF'
-tmp_dir: /das/work/p21/p21515/.cache/Pmodules
-download_dir: /das/work/p21/p21515/.cache/Pmodules/distfiles
-EOF
-```
-
-Then:
+Build tmp and download cache MUST be on /das, not the defaults
+(/var/tmp is too small, the tarball alone blows the $HOME quota — a
+download dying with "Failure writing output to destination" means
+exactly that). Pass both dirs explicitly on the command line so there
+is no doubt where things land — **adapt the p-group path
+(`p21/p21515`) to your own**:
 
 ```bash
 module use unstable && module load modbuild/2.1.3
 cd ccp4
-modbuild build --prep 9.0   # download/cache only; also verifies tmp_dir took effect
-modbuild build 9.0
+mkdir -p /das/work/p21/p21515/.cache/Pmodules
+modbuild build \
+    --tmpdir=/das/work/p21/p21515/.cache/Pmodules \
+    --distdir=/das/work/p21/p21515/.cache/Pmodules \
+    --clean-install -v --debug 9.0
 ```
 
+(`--clean-install` removes a previous broken install first; `-v
+--debug` make the otherwise silent long steps visible.)
+
+Alternative: `~/.Pmodules/Pmodules.yaml` with top-level `tmp_dir:` and
+`download_dir:` keys sets the same defaults per user — but in practice
+`download_dir` did not reliably take effect there, so the explicit
+flags above are the maintained route.
+
 If the download fails (expired sid), fetch a fresh link from
 https://www.ccp4.ac.uk/download/ and update `files/config.yaml`, or drop a
 hand-downloaded tarball into the distfiles dir under the `name:` given in
@@ -65,12 +69,12 @@ Growing `du` = working. Only investigate if it's frozen for 10+ min.
 - **"done" but broken install**: modbuild has no errexit in hooks — errors in
   `pbuild::install` used to scroll by and the build still reported done. The
   build script now `std::die`s on every critical step.
-- **Interrupted download**: prep now detects a truncated tarball with
-  `gzip -t` and resumes it with `wget --continue` — just re-run
-  `modbuild build 9.0`. A download that dies with
+- **Interrupted download**: prep detects a truncated tarball with
+  `gzip -t` and resumes it with `wget --continue` — just re-run the
+  build command above. A download that dies with
   `Failure writing output to destination` means quota/disk full at the
-  distfiles dir, not a network problem — free space or move `download_dir:`
-  (see above) before retrying.
+  distfiles dir, not a network problem — check `--distdir` points to
+  /das before retrying.
 - The tarball unpacks to `ccp4-9` (not `ccp4-9.0` as the CCP4 install doc
   implies); the build globs `ccp4-*/` instead of assuming the name.