A discrepancy in `sys_tags` handling causes `poetry install` to fail on macos

• Poetry version: 1.2.2
• Python version: 3.9
• OS version and name: macos-12
• pyproject.toml:

[tool.poetry]
name = "macos-ci-testing"
version = "0.1.0"
description = "Just testing"
authors = []

[tool.poetry.dependencies]
python = "~3.9.0"
pyobjc-framework-SystemConfiguration = "^8"

[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

• I am on the latest stable Poetry version, installed using a recommended method.
• I have searched the issues of this repo and believe that this is not a duplicate.
• I have consulted the FAQ and blog for any relevant entries or release notes.
• If an exception occurs when executing a command, I executed it again in debug mode (-vvv option) and have included the output below.

Issue

After an update in the macos-12 images from github actions, our CI job on macos started to fail during poetry install with the following error (fulltrace here):

...
ERROR: pyobjc_framework_SystemConfiguration-8.5.1-cp36-abi3-macosx_11_0_universal2.whl is not a supported wheel on this platform.
...

I managed to reproduce the error in a new repository with minimal configuration: https://github.com/vxgmichel/macos-ci-testing

The workflow is really simple too:

  test-macos:
    name: macOS
    runs-on: macos-12
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-python@v4
        with:
          python-version: "3.9"
      - name: Install poetry
        run: pip3 install poetry packaging
      - name: Run debug script
        run: python debug.py
      - name: Install project
        run: poetry install -vvv

After a quick investigation, I noticed something weird: packaging.tags.sys_tags and poetry.core._vendor.packaging.tags.sys_tags do not provide the same tag list.

In particular, this debug.py script yields:

Looking for 'cp36-abi3-macosx_11_0_universal2':
- in `sys_tags` provided by packaging: True
- in `sys_tags` provided by poetry: False

The full difference can be found here.

I suspect that different implementations of sys_tags are used to:

• first, choose which wheel to download
• then, when installing, check that the wheel is supported

This is as far as I can get with my limited knowledge of poetry, and I might be missing something else.

[neersighted]

That is an insufficient work around as we will just see it manifest in reverse with the next pip release. I have discussed another approach with a pip maintainer I will try to prepare today.

[vxgmichel]

it seems clear that Something Should Be Done.

In the meantime, a possible workaround for affected users is setting the SYSTEM_VERSION_COMPAT env var to 0.

env:
  SYSTEM_VERSION_COMPAT: "0"

https://github.com/vxgmichel/macos-ci-testing/commit/5c707197acdb47c6032737009f17389f3c6a131e