# Dependency resolution conflict on universal2 with pip 22.3 and Python 3.11

**URL:** <https://discuss.python.org/t/dependency-resolution-conflict-on-universal2-with-pip-22-3-and-python-3-11/20419>\
**Category:** Packaging\
**Created:** [October 27, 2022, 7:32am UTC](https://discuss.python.org/t/dependency-resolution-conflict-on-universal2-with-pip-22-3-and-python-3-11/20419 "2022-10-27T07:32:23Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![pitrou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pitrou/32/28_2.png) [@pitrou](https://discuss.python.org/u/pitrou)\
**Post date:** [October 27, 2022, 7:32am UTC](https://discuss.python.org/t/dependency-resolution-conflict-on-universal2-with-pip-22-3-and-python-3-11/20419/1 "2022-10-27T07:32:23Z")

</div>

Hello,

We’re trying to build PyArrow binary wheels for Python 3.11. Everything works fine _except_ for macOS `universal2` with Python 3.11, which fails on a bizarre pip `ResolutionImpossible` error when building the `arm64` part of the wheel (we build first the `arm64` part, then the `x86` part, then merge them).

(note that building a `arm64` wheel works fine however!)

The pip error message is unfortunately not really actionable, it’s not obvious what the problem is:

```auto
ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts
The conflict is caused by:
    oldest-supported-numpy 2022.8.16 depends on numpy==1.23.2; python_version == "3.11" and platform_python_implementation != "PyPy"
    oldest-supported-numpy 2022.5.28 depends on numpy; python_version >= "3.11"
    oldest-supported-numpy 2022.5.27 depends on numpy; python_version >= "3.11"
    oldest-supported-numpy 2022.4.18 depends on numpy; python_version >= "3.11"
    oldest-supported-numpy 2022.4.10 depends on numpy; python_version >= "3.11"
    oldest-supported-numpy 2022.4.8 depends on numpy; python_version >= "3.11"
    oldest-supported-numpy 2022.3.27 depends on numpy; python_version >= "3.11"
    oldest-supported-numpy 2022.1.30 depends on numpy; python_version >= "3.11"
    oldest-supported-numpy 0.15 depends on numpy; python_version >= "3.11"
    oldest-supported-numpy 0.14 depends on numpy; python_version >= "3.11"

```

Full CI build log is here:

> <https://github.com/ursacomputing/crossbow/actions/runs/3332186845/jobs/5512768206#step:9:1>

More context:

> <https://github.com/apache/arrow/pull/14499>
>
> This PR adds jobs to build pyarrow wheels for Python 3.11.

---

<div class="post-metadata">

**Author:** ![jorisvandenbossche](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jorisvandenbossche/32/658_2.png) [@jorisvandenbossche](https://discuss.python.org/u/jorisvandenbossche)\
**Post date:** [October 27, 2022, 7:51am UTC](https://discuss.python.org/t/dependency-resolution-conflict-on-universal2-with-pip-22-3-and-python-3-11/20419/2 "2022-10-27T07:51:14Z")

</div>

We figured out the reason: we specified `--platform macosx_10_14_arm64` while also needing numpy 1.23.2 (as shown in the pip conflict message above), but this version of numpy no longer provides universal2 wheels that match that platform (only 10\_9\_x86\_64 and 11\_0\_arm64 wheels).

So there is basically no suitable wheel available (since also `--only-binary=:all:` is set) for the constraints we set ourselves. But, I would say that the conflict message of pip is still unclear and not actionable, and didn’t really help to figure this out.

---

<div class="post-metadata">

**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\
**Post date:** [October 27, 2022, 8:51am UTC](https://discuss.python.org/t/dependency-resolution-conflict-on-universal2-with-pip-22-3-and-python-3-11/20419/3 "2022-10-27T08:51:19Z")

</div>

Thanks for confirming you found the cause. The inadequate error message is something we are aware of, but we haven’t been able to find an effective strategy for improving it yet. If anyone is interested in helping out, we’d be very grateful…