Skip to content

chore: automated python requirements upgrades - #2

Open
github-actions[bot] wants to merge 1 commit into
mainfrom
auto-dependency-upgrades
Open

chore: automated python requirements upgrades#2
github-actions[bot] wants to merge 1 commit into
mainfrom
auto-dependency-upgrades

Conversation

@github-actions

Copy link
Copy Markdown

@asalzburger
asalzburger force-pushed the main branch 3 times, most recently from 4cbe66e to 5b3b3c8 Compare September 25, 2025 10:53
@github-actions
github-actions Bot force-pushed the auto-dependency-upgrades branch from e2484a7 to 0197b71 Compare September 28, 2025 02:05
@github-actions
github-actions Bot force-pushed the auto-dependency-upgrades branch 2 times, most recently from 8224ba4 to 548c13a Compare October 12, 2025 02:03
@github-actions
github-actions Bot force-pushed the auto-dependency-upgrades branch from 548c13a to 7ce7405 Compare October 19, 2025 02:05
@github-actions
github-actions Bot force-pushed the auto-dependency-upgrades branch from 7ce7405 to 676708d Compare October 26, 2025 02:05
@github-actions
github-actions Bot force-pushed the auto-dependency-upgrades branch from 676708d to 4dd7496 Compare November 16, 2025 02:05
@github-actions
github-actions Bot force-pushed the auto-dependency-upgrades branch 2 times, most recently from d24e507 to 684512a Compare November 30, 2025 02:06
@github-actions
github-actions Bot force-pushed the auto-dependency-upgrades branch from 684512a to 5fb0698 Compare December 7, 2025 02:05
@github-actions
github-actions Bot force-pushed the auto-dependency-upgrades branch from 5fb0698 to 270e303 Compare December 14, 2025 02:06
@github-actions
github-actions Bot force-pushed the auto-dependency-upgrades branch from 270e303 to 1a36b12 Compare December 21, 2025 02:06
@github-actions
github-actions Bot force-pushed the auto-dependency-upgrades branch from 1a36b12 to 302623c Compare December 28, 2025 02:06
@github-actions
github-actions Bot force-pushed the auto-dependency-upgrades branch from 302623c to 2c1d230 Compare January 4, 2026 02:06
@github-actions
github-actions Bot force-pushed the auto-dependency-upgrades branch from 2c1d230 to 069c2c1 Compare January 11, 2026 02:06
@github-actions
github-actions Bot force-pushed the auto-dependency-upgrades branch 2 times, most recently from 15d51e3 to 3f1777f Compare January 25, 2026 02:06
@github-actions
github-actions Bot force-pushed the auto-dependency-upgrades branch 2 times, most recently from fae6f6b to 7b3a771 Compare February 22, 2026 02:07
@github-actions
github-actions Bot force-pushed the auto-dependency-upgrades branch from 7b3a771 to 84c9d7c Compare March 1, 2026 02:07
@github-actions
github-actions Bot force-pushed the auto-dependency-upgrades branch from 84c9d7c to ccd8a3d Compare March 8, 2026 02:06
@github-actions github-actions Bot added the Stale label Apr 24, 2026
asalzburger pushed a commit that referenced this pull request Aug 10, 2026
…cts-project#5742)

**Stacked on acts-project#5719.** Its commits appear in this diff until it merges; review this PR's own commits only, and it will be rebased onto `main` once acts-project#5719 lands. The remaining merge conflicts are all in `requirements.txt` lockfiles owned by acts-project#5719, not by this PR.

This PR's own contribution is two files: `CI/repair_wheel_macos.sh` and the three-line change wiring it up in `CI/cibuildwheel.sh`.

## Context

The PyPI nightly has two independent failures, both introduced by acts-project#5659:

1. **Linux** — cp310 test-requirements unresolvable. **Fixed by acts-project#5719** (drops Python 3.10, universal lockfiles).
2. **macOS** — `delocate-wheel` fails with `Already planning to copy library with same basename as: libssl.3.dylib`. Not addressed anywhere else; this PR targets it.

Failure #2 is Python-version-independent (it's about the wheel's linked dylibs), so acts-project#5719 alone leaves the macOS wheel red.

## Root cause

Confirmed from CI diagnostics (`delocate-listdeps --all --depending` on the un-repaired wheel). Enabling `ACTS_BUILD_PLUGIN_ARROW` + `ACTS_ARROW_ISOLATED` for wheels makes the macOS wheel link openssl **twice, from two different prefixes**:

| Consumer | openssl it links |
|---|---|
| `libActsPluginArrow.dylib` (static Arrow) | spack's — `.../spack/opt/spack/darwin-aarch64/openssl-3.6.1-u37gbox7.../lib/libssl.3.dylib` |
| `libthrift.0.22.0.dylib` (spack, an Arrow dependency) | the python.org framework's — `/Library/Frameworks/Python.framework/Versions/3.14/lib/libssl.3.dylib` |

`libthrift` is the *only* thing pulling in the framework copy. delocate cannot vendor two libraries sharing a basename, so it aborts.

Note this is **not** a spack lockfile problem: the macOS lockfile contains a single openssl. The second copy comes from spack's `thrift` having been linked against the framework openssl instead of its own.

Upgrading delocate does not help (0.13.0, latest, still fails) — these are genuinely two different files, not a symlink pair.

## The fix

`CI/repair_wheel_macos.sh`, wired up as `CIBW_REPAIR_WHEEL_COMMAND_MACOS`. Before delocating, it repoints any spack library referencing the framework openssl at the spack openssl, collapsing the graph to a single copy. Both are openssl 3.x, and ACTS' Parquet usage does not touch TLS.

It only mutates the spack store on the ephemeral CI runner; delocate re-signs whatever it vendors, so the invalidated store-lib signatures don't matter, and the wheel's tests then run against the self-contained wheel.

The script is deliberately conservative:

- derives the spack root from whatever spack path the wheel actually links, rather than hard-coding a layout;
- **no-ops** when the wheel doesn't link spack at all (e.g. Arrow disabled);
- **no-ops** when nothing references the framework openssl — so it self-disables once the proper fix lands, instead of rotting into a permanent hack;
- fails loudly if `install_name_tool` fails or the target openssl is missing, rather than masking it into a confusing delocate error;
- dumps the dependency tree if delocate still fails.

### This is a workaround

The proper fix belongs in **ci-dependencies**: build `thrift` against spack's own openssl, or drop openssl from that build entirely (Parquet needs no TLS). This unblocks the wheels until then, and reverts to a no-op automatically once that happens.

## Validation

End-to-end macOS wheel build on `macos-26` (cp311), confirming the whole chain:

```
spack root: /Users/runner/work/acts/acts/spack
  .../thrift-0.22.0-.../lib/libthrift.0.22.0.dylib:
    /Library/Frameworks/Python.framework/Versions/3.14/lib/libssl.3.dylib
      -> .../openssl-3.6.1-u37gbox7.../lib/libssl.3.dylib
  (same for libcrypto.3.dylib)
rewrote 2 framework openssl reference(s)
```

delocate then vendored exactly one copy of each:

```
Copying library .../openssl-3.6.1-u37gbox7.../lib/libssl.3.dylib    -> acts/.dylibs/libssl.3.dylib
Copying library .../openssl-3.6.1-u37gbox7.../lib/libcrypto.3.dylib -> acts/.dylibs/libcrypto.3.dylib
```

and the wheel's own test suite passed against the repaired wheel: `12 passed, 373 deselected`. That last point matters — it confirms the rewritten linkage actually loads at import time, not just that delocate stopped complaining.

The script's branches were additionally exercised locally against the real linkage topology captured from the CI artifact, with mocked `otool` / `install_name_tool` / `delocate-wheel`: it reproduces the original `DelocationError` without the fix, and no-ops correctly both when the wheel has no spack references and when `thrift` already points at spack's openssl.

The temporary push-triggered diagnostics workflow used to iterate on this has been removed.

## Before merging

- [x] End-to-end macOS wheel build green
- [x] Delete the temporary diagnostics workflow
- [x] Rebase onto `main` once acts-project#5719 lands

🤖 Generated with [Claude Code](https://claude.com/claude-code)


Co-authored-by: Benjamin Huth <37871400+benjaminhuth@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants