graphics/py-{pillow,pillow6}: Introduce PY_PILLOW macro

[koobs]

Summary

This is a follow up to rP526962 and introduces a PY_PILLOW macro to python.mk
with the appropriate conditional to choose between the Pillow packages.

* Remove the conditionals of the affected ports as the logic is now
  available in python.mk.

* Replace the remaining occurences of graphics/py-{pillow,pillow6} with the
  new PY_PILLOW macro.

* No bump of PORTREVISION as the logic was already implemented and the bumps
  were done in r526962.

Requested by: portmgr (antoine)

Test Plan

• poudriere -n -a -t -> OK
• poudriere bulk against all Pillow 6 / 7 consumers -> OK (113Ramd64 for py27,py35,py36,py37,py38)

[koobs]

Every Python package that declares a dependency that includes a <version-spec> cant be accurately or correctly described using a shared dependency line

It doesn't even matter whether or not the Python package declares the <version-spec> correctly or not. Whatever is specified in setup.py *must* be 'exactly' satisfied, otherwise it results in a runtime dependency error (even when the dependency is installed).

via https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243665#c10

All existing shared dependency lines in python.mk have the same issue.

[antoine]

Mk/Uses/python.mk

634

Please put this in the same block as PY_TYPING

[kai]

Address @antoine's pointer and rebase, as x11-toolkits/py-kivy is gone now.

[kai]

As @koobs already stated in the related Bugzilla issue and here on the review:

Assume a port has pillow >=7.0.0,<=7.2.0 in its setup.py and that dependency is only checked at runtime. That port would break silently when upgrading graphics/py-pillow to a higher version, e.g. 7.3.0.

For example we had likewise and recent cases with the www/mitmproxy port that broke silently several times when some dependencies were upgraded because the listed dependencies in setup.py were only checked at runtime.

For such a case I can only think of make an exception by adding those requirements explicitly into a Makefile instead using the ${PY_PILLOW} macro. Unless there's another way?

Hence I see adding the PY_PILLOW as a temporary solution to avoid build failures (= bulk -a)/package conflicts until Python 2.7 is gone from the Ports tree to the end of this year. What does each of you think about it?

[antoine]

This looks fine. Thanks.

[antoine]

What is this waiting for?

[koobs]

Hey, meant to follow this up sooner but the last few weeks have been crazy. Shared dependencies are incompatible with the way Python tracks versions. The Python team will be discussing ways to ensure the accuracy of Python port dependencies, which shared/common macros preclude. We're looking to remove the existing ones once we're ready.

[antoine]

@kai : please commit this, requested and approved by portmgr.