graphics/py-cairocffi: Update to 1.0.2

[koobs]

Summary

graphics/py-cairocffi: Update to 1.0.2

  - Update COMMENT, match upstream setup.py:description
  - Update USES=python, now only supports Python 3.x
  - Switch to autoplist (using --record), update pkg-plist to add missing
    files until resolved upstream [1][2][3]

Changelog:

  https://github.com/Kozea/cairocffi/blob/v1.0.2/NEWS.rst
  
[1] https://github.com/Kozea/cairocffi/issues/108
[2] See Also: https://github.com/spatialaudio/python-sounddevice/issues/116
[3] See Also: https://groups.google.com/forum/#!topic/python-cffi/oX2T_Y5m99I

PR:		237884
Reviewed_by:	dch (maintainer)
Approved by:	dch (maintainer)
Differential_Revision: D20352

Test Plan

• portlint: OK (looks fine.)
• testport: OK (poudriere: 12amd64py36)
• maketest: OK (6 failed, 40 passed, 7 skipped) [4]

[4] Several UnicodeEncodeErrors, and 2x assert 20.0 > 20.0, report upstream

[mat]

graphics/py-cairocffi/Makefile

28

PYTHON_PYOEXTENSION was removed from PLIST_SUB because for the 3.5+ case, it is always opt-1.pyc. Why add it back here? It would probably be better to simply write opt-1.pyc in the plist file, as it is a constant.

[dch]

thanks koobs; however 0.9.0 is the last working version for python 2.7. Can we do a small bump (per my BZ patch) to 0.9.0, and wait for 2020/01/01 to move to 1.0.2? I'd prefer this as it will break anybody who hasn't gone through their own personal pycopalypse yet...

wrt dependencies of this port:

• qtile is marked broken upstream for some time
• graphite-api I need to check
• py-gizeh should be fine according to requirements.txt /cc yuri@ can you check this?

[koobs]

In D20352#438850, @dch wrote:

thanks koobs; however 0.9.0 is the last working version for python 2.7. Can we do a small bump (per my BZ patch) to 0.9.0, and wait for 2020/01/01 to move to 1.0.2? I'd prefer this as it will break anybody who hasn't gone through their own personal pycopalypse yet...

I understand and agree with the user consideration (it is noble and warranted to think about it), though we shouldn't hold back updates to ports because they move to Python 3.x, modulo making sure that the updates work with existing in-ports-tree consumers (like below). This principle applies similarly to any port, not just python ones, that move to only support specific versions of their dependencies.

If we're seriously concerned about Python 2.x ports being important to users, we can create specific versions that are Python 2.x safe for users, such as a py-cairocffi09, though I'm not sure the effort is worth the reward (and maintenance), given users can pip install --user or in a virtualenv any version of any Python package they want, or hold off (pkg lock) updating a specific port/package.

wrt dependencies of this port:

• qtile is marked broken upstream for some time
• graphite-api I need to check
• py-gizeh should be fine according to requirements.txt /cc yuri@ can you check this?

[koobs]

graphics/py-cairocffi/Makefile

28

I'll remove it in this instance given the lack of use in the tree after its recent removal, but it's actually variable.

It's only the same at the moment as we specify PYDISTUTILS_INSTALLARGS=-O1 in python.mk, but there are other values, which we may want to use/change to.

Python can also change the format at any time, conditionally based on build type or globally, as it has in the past, which is a better argument than our -O1 use for keeping it a variable.

Currently, a changing format would require sweeping every pkg-plist in the tree.

But let's cross that bridge when we come to it.

[koobs]

graphics/py-cairo: Remove PYO_EXTENSION references

[dch]

per irc, lets do this - over to koobs for the coup de grace.