[CI] Set PIP_PREFER_BINARY in tox as a workaround for problems in macOS

[abravalheri]

Summary of changes

Closes #5105

Pull Request Checklist

• Changes have tests
• News fragment added in newsfragments/.
  (See documentation for details)

[abravalheri]

it seems that this approach make other tests fail.

[abravalheri]

The test failure seems to be caused by #5108, the same problem was found in #5017.
So maybe PIP_PREFER_BINARY works?

[Avasam]

I know this is currently a workaround, but if it works (let's see after #5108) I feel like this is correct to keep long term: you want to avoid surprise breakage (or extra long installs) due to transitive dependencies suddenly releasing a new version that drops support for an older Python version that setuptools still supports. (meaning the comment could be updated to reflect that).

I think this failure wouldn't affect end-users using PEP-517, build isolation, and

[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"

given that setuptools doesn't declare any dependency by default, (so they won't be downloaded by build frontend, and setuptools will use its vendored deps).

Surprise failures like this could affect users of setuptools[core] if you ever end up with such transitive deps in core. But even in this specific current scenario, pyobjc was only included because of setuptools[test] > jaraco.path > pyobjc, setuptools[test] > jaraco.develop > jaraco.vcs > jaraco.path > pyobjc and setuptools[doc] > rst.linker > jaraco.vcs > jaraco.path > pyobjc.

---

tl;dr: I think this is more than a workaround, and actually the correct long-term config.

[abravalheri]

Thanks @Avasam, I agree with your assessment.
I think that in terms of maintenance this is the best option.

I think that ideally setuptools[core] should never get a non-pure-python dependency (with the exception of build systems which are assumed to be pre-installed)... but that is a bit hard to check.

The alternative would be introducing a constraint file only for pyobjc, and then keep being prone to these kinds of flukes in the CI...

[Avasam]

Assuming PIP_PREFER_BINARY was picked-up correctly, is it possible pip's resolver is not sophisticated enough to walk back to the pyobjc dependency to try a lower bound to avoid pyobjc-*==12 ?

[abravalheri]

Yes, I think that may be the case... so maybe the only alternative is to use something similar to #5107.