Commit 4fe3d63
authored
Fix wheel naming on macOS for single-arch rebuilds (DataDog#20699)
While working on DataDog/datadog-agent#38582, I realized `arm64` shared
libraries could surprisingly be pulled into `x86_64` DMGs, for instance:
```json
{
"path": "datadog-agent-7.69.0-devel.git.364.9cd4057.pipeline.70042062-1.dmg/datadog-agent-7.69.0-devel.git.364.9cd4057.pipeline.70042062-1.pkg/datadog-agent-core.pkg Contents/Payload/opt/datadog-agent/embedded/lib/python3.12/site-packages/confluent_kafka/.dylibs/liblmdb.so",
"digestAlgorithm": "SHA-256",
"cdhash": "5c30429cac77cd7a04f798957cd6c4ea876555d4",
"arch": "arm64"
}
```
(https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1020563452)
It would be perfectly fine if that shared library would embed multiple
architectures in addition to the `x86_64` target, but it's clearly not
the case for `confluent_kafka` that we rebuild and repackage as a
single-architecture wheel.
The selection of the wheel to pin in the lock file is based on a filter
that accepts `universal2` for both architectures:
```py
'macos-x86_64': 'macosx.*_(x86_64|intel|universal2)',
'macos-aarch64': 'macosx.*_(aarch64|arm64|universal2)',
```
(https://github.com/DataDog/integrations-core/blob/80e9e635ef25806f1501ebe0d2d37740f180bd69/.builders/lock.py#L25-L26)
A problem is that available wheels are treated in the order returned by
the cloud storage API (https://agent-int-packages.datadoghq.com), which
means the latest iterated over for a given version will be considered in
the final selection, independently from other factors like the build
timestamp or the macOS version:
```py
build_number = int(build[0]) if build else -1
candidates[build_number] = blob
```
(https://github.com/DataDog/integrations-core/blob/80e9e635ef25806f1501ebe0d2d37740f180bd69/.builders/lock.py#L112-L113)
Practically speaking, which one of the following wheels will be picked
relies on the order in which they're returned by the cloud storage API:
- `confluent_kafka-2.8.0-20250707163239-cp312-cp312-macosx_10_12_universal2.whl`
- `confluent_kafka-2.8.0-20250707163256-cp312-cp312-macosx_11_0_universal2.whl`
- `confluent_kafka-2.8.0-20250707171022-cp312-cp312-macosx_10_12_universal2.whl`
- `confluent_kafka-2.8.0-20250707171037-cp312-cp312-macosx_11_0_universal2.whl`
The present change aims at decreasing the probability `arm64`-only
shared libraries get transitively depended on by `x86_64` targets and
the other way around.
In the above example, this would limit the wheels being considered to
applicable architectures - for `x86_64`:
- `confluent_kafka-2.8.0-20250707163239-cp312-cp312-macosx_10_12_x86_64.whl`
- `confluent_kafka-2.8.0-20250707171022-cp312-cp312-macosx_10_12_x86_64.whl`
... and, for `arm64`:
- `confluent_kafka-2.8.0-20250707163256-cp312-cp312-macosx_11_0_arm64.whl`
- `confluent_kafka-2.8.0-20250707171037-cp312-cp312-macosx_11_0_arm64.whl`1 parent be5c0b2 commit 4fe3d63
1 file changed
Lines changed: 9 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
228 | 228 | | |
229 | 229 | | |
230 | 230 | | |
| 231 | + | |
| 232 | + | |
231 | 233 | | |
232 | 234 | | |
233 | 235 | | |
| |||
277 | 279 | | |
278 | 280 | | |
279 | 281 | | |
| 282 | + | |
| 283 | + | |
| 284 | + | |
280 | 285 | | |
281 | 286 | | |
282 | | - | |
| 287 | + | |
283 | 288 | | |
| 289 | + | |
| 290 | + | |
284 | 291 | | |
285 | | - | |
| 292 | + | |
286 | 293 | | |
287 | 294 | | |
288 | 295 | | |
| |||
0 commit comments