Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Docker build fails on Apple Silicon (arm64) — only x86_64 wheels pinned for extractcode-7z, extractcode-libarchive, typecode-libmagic

Offen Anfängerfreundlich
#2,426 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
86/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
docker, docker-compose, python
Bereich
build-system

Rechercherichtung

Prüfe requirements.txt und requirements-dev.txt auf die festgelegten Versionen von extractcode-7z, extractcode-libarchive und typecode-libmagic, die auf .210531 gesetzt sind. Aktualisiere beide Dateien auf die kompatiblen älteren Pins, die im Report vorgeschlagen werden, damit alle Umgebungen dieselbe Änderung erhalten. Reproduziere das Problem mit make envfile und anschließend docker compose build auf einem Apple-Silicon-Setup (arm64/aarch64). Als erledigt gilt die Aufgabe, wenn der Build erfolgreich ohne den Fehler ResolutionImpossible durchläuft.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Summary

docker compose build fails on native Apple Silicon (arm64) with a pipResolutionImpossible error.
This doesn't seem to be a version conflict but is instead caused due to the pinned versions
of three native dependencies in requirements.txt and requirements-dev.txt only shipping x86_64 wheels,
with no arm64 or aarch64 build available.

Environment

  • macOS Ventura 13.7.3, Apple Silicon
  • Docker via Colima (--arch aarch64 --vm-type=vz)
  • Fresh clone, no other modifications

Steps to reproduce

  1. Clone the repo on an Apple Silicon Mac
  2. make envfile
  3. docker compose build

Actual behavior

ERROR: Cannot install extractcode[full]==31.0.0 because these package versions have conflicting dependencies.

The conflict is caused by:
extractcode[full] 31.0.0 depends on extractcode-7z>=16.5.210525; extra == "full"
The user requested (constraint) extractcode-7z==16.5.210531

ERROR: ResolutionImpossible

Root cause

requirements.txt and requirements-dev.txt both pin:

  • extractcode-7z==16.5.210531
  • extractcode-libarchive==3.5.1.210531
  • typecode-libmagic==5.39.210531

Checking PyPI, these specific versions publish wheels only for win_amd64,
manylinux1_x86_64, and macosx_10_14_x86_64.
No arm64/aarch64 wheels are available for .210531 for any of the three packages.
On an Apple Silicon host, pip therefore has no compatible wheel
available to satisfy the pinned versions. However, it reports a dependency conflict
rather than clearly indicating that a compatible wheel is unavailable,
which obscures the actual cause of the installation failure.

Proposed fix

The immediately preceding releases of the same three packages do ship
arm64 wheels, and still satisfy the >= minimums that extractcode[full]
and typecode[full] declare:

Package Current pin Proposed pin Satisfies declared minimum?
extractcode-7z 16.5.210531 16.5.210525 yes (>=16.5.210525)
extractcode-libarchive 3.5.1.210531 3.5.1.210525 yes (>=3.5.1.210525)
typecode-libmagic 5.39.210531 5.39.210223 yes (>=5.39.210223)

This needs to be applied to both requirements.txt and requirements-dev.txt.
They pin these separately so fixing only one still breaks the other.

Verification

With the above three-line change in both files:

  • docker compose build completes natively as arm64
  • Full stack (postgres, redis, nginx, web, scheduler, both rqworkers)
    boots cleanly
  • Test suite: 882 passed, 1 skipped, 1 failed — the one failure is
    unrelated and caused by a git-commit-hash injection into settings.py

Happy to open a PR with this fix if it's welcome — wanted to inquire
whether there was a reason these specific versions were pinned.

Vorherrschende Sprache
Python
Sterne
716
Forks
347
Ø Merge
13 Std. 47 Min.
Gemergte PRs (30 T.)
8

Entwicklungsumgebung

  • Enthält ein Dockerfile oder eine Docker-Compose-Datei
  • Keine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus aboutcode-org/vulnerablecode

Alle Issues in aboutcode-org/vulnerablecode

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.