Fix plist issue (caused by namespace package) with python35

[sunpoet]

Summary

namespace package will be skipped during installation. Since Python 3.5, .pyo files are removed and new .opt-1.pyc files are introduced [1]. However setuptools does not understand that new naming therefore packaging failed.

[1] https://www.python.org/dev/peps/pep-0488/

% cd /usr/ports/net/py-ndg_httpsclient
% make
...
===>   Generating temporary packing list
running install
running build
running build_py
running install_lib
Skipping installation of /usr/ports/works/usr/ports/net/py-ndg_httpsclient/work/stage/usr/local/lib/python3.5/site-packages/ndg/__init__.py (namespace package)
...

% make check-plist
====> Checking for pkg-plist issues (check-plist)
===> Parsing plist
===> Checking for items in STAGEDIR missing from pkg-plist
===> Checking for items in pkg-plist which are not in STAGEDIR
Error: Missing: %%PYTHON_SITELIBDIR%%/ndg/__pycache__/__init__.cpython-35.opt-1.pyc
===> Error: Plist issues found.
*** Error code 1

Stop.
make: stopped in /usr/ports/net/py-ndg_httpsclient

Test Plan

• Add DEFAULT_VERSIONS=python=3.5 to /etc/make.conf
• Build net/py-ndg_httpsclient

[koobs]

Is this reproducible in the latest version of setuptools?
Has this been fixed upstream?

I'm very wary (given previous efforts/experience) to carry local patches for python packaging. We've worked very hard to rid ourselves of legacy

[sunpoet]

In fact, I updated setuptools to latest version (18.5) and found problem unsolved. Then I try to read the code and find the reason.

[koobs]

At a minimum I think we need to have it reported upstream in an issue/bug report, with a reference above the conditional.

If setuptools doesn't support the Python ecosystems own packaging rules, well ..

1. How does pip handle this right now, since it depends on and uses setuptools. Maybe its been patched too
2. If we report it upstream, we're likely to get way more insight/feedback on the extent to which this is considered a 'bug' or not, along with alternative approaches to fixing the problem, if indeed it turns out to be a 'bug'.
3. How does the test suite fair in terms of success/failure delta before/after this change?

I'm guessing if this change lands, that it should also be MFH'd. If that's the case we dont need to do the version update (and other modernization changes like do-test:). If no MFH, shouldnt we refresh the version while we're here?

[antoine]

Can you re-upload the extra-patch-setuptools-command-install_lib.py patch or put it somewhere? it seems empty

[koobs]

Oh yeh, thats the arc(8) bug with no content for newly created files issue again cc @eadler :)

[sunpoet]

I put the extra patch at http://people.freebsd.org/~sunpoet/extra-patch-setuptools-command-install_lib.py.txt

[sunpoet]

The patch has been merged by usptream [1]. Let's wait for new release. :)

[1] https://bitbucket.org/pypa/setuptools/pull-requests/158/fix-package-list-inconsistency-caused-by/diff