https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270358

--- Comment #139 from Charlie Li <[email protected]> ---
(In reply to Kevin Bowling from comment #138)
You don't get to make threats like this either, especially not with unpaid
volunteers. The one who is most angry and feeling burnt out without actually
being burnt out is me. Until you have actually witnessed, dealt with and
reconciled all the breaking changes, on top of all the whining from everyone
who don't have a clue, continuing these comments don't help. The way you (and
everyone else) can help is by following directions.

And speaking of breakages, I'm not even through the USE_PYTHON=distutils
portion of the exp-run (USE_PYTHON=pep517 consumers to run separately) and we
already have some common themes:

A number of consumers fail stage-qa because tests are getting installed into
${PYTHON_SITELIBDIR} (site-packages) as its own package/namespace. This is due
to improper package discovery practices (from devel/py-homebase):
Error: Python package installs top-level 'test/' directory in site-packages
Error:   Location: lib/python3.11/site-packages/test
Error: This causes file conflicts with other packages. Exclude it via
pyproject.toml:
Error:   [tool.setuptools.packages.find]
Error:   exclude = ["test", "test.*"]
Error: See:
https://setuptools.pypa.io/en/latest/userguide/package_discovery.html

I'm inclined to mark these cases BROKEN since these are more likely to not have
as much recent upstream activity in any form.

www/py-html5lib still references a number of ancient setuptools (ie < 26)
primitives, ostensibly for maximum compatibility with even EOLed Python. A
fork, www/py-html5lib-modern, still uses references pkg_resources (as does
www/py-html5lib). This is removed in 82 and later, which is why this PR holds
on 81, but nonetheless prints a huge deprecation notice. The remaining
pkg_resources is not guaranteed to work properly, and this non-guarantee is hit
here. Given that the upstream repository has not had commit or other maintainer
activity in about two years, some local patching may be warranted, which would
be covered in a separate PR referencing this one. This port gets its own
mention due to blocking many other ports from being built/tested, particularly
those with active upstream activity.

A few others have version specifiers that violate the Python packaging
standards.

More to come.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Reply via email to