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
- Clone the repo on an Apple Silicon Mac
make envfile
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.
Summary
docker compose buildfails on native Apple Silicon (arm64) with a pipResolutionImpossibleerror.This doesn't seem to be a version conflict but is instead caused due to the pinned versions
of three native dependencies in
requirements.txtandrequirements-dev.txtonly shipping x86_64 wheels,with no arm64 or aarch64 build available.
Environment
--arch aarch64 --vm-type=vz)Steps to reproduce
make envfiledocker compose buildActual behavior
Root cause
requirements.txtandrequirements-dev.txtboth pin:extractcode-7z==16.5.210531extractcode-libarchive==3.5.1.210531typecode-libmagic==5.39.210531Checking 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 thatextractcode[full]and
typecode[full]declare:extractcode-7z16.5.21053116.5.210525>=16.5.210525)extractcode-libarchive3.5.1.2105313.5.1.210525>=3.5.1.210525)typecode-libmagic5.39.2105315.39.210223>=5.39.210223)This needs to be applied to both
requirements.txtandrequirements-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 buildcompletes natively as arm64boots cleanly
unrelated and caused by a git-commit-hash injection into
settings.pyHappy to open a PR with this fix if it's welcome — wanted to inquire
whether there was a reason these specific versions were pinned.