After the update to 4.12.2 (and now static plist), 'make -C www/py-beautifulsoup stage check-plist' fails (and 'make install' fails as well for the same reason). ===> Checking for items in STAGEDIR missing from pkg-plist Error: Orphaned: %%PYTHON_SITELIBDIR%%/bs4/__pycache__/__init__.cpython-37.opt-1.pyc Error: Orphaned: %%PYTHON_SITELIBDIR%%/bs4/__pycache__/__init__.cpython-37.pyc Error: Orphaned: %%PYTHON_SITELIBDIR%%/bs4/__pycache__/css.cpython-37.opt-1.pyc Error: Orphaned: %%PYTHON_SITELIBDIR%%/bs4/__pycache__/css.cpython-37.pyc Error: Orphaned: %%PYTHON_SITELIBDIR%%/bs4/__pycache__/dammit.cpython-37.opt-1.pyc Error: Orphaned: %%PYTHON_SITELIBDIR%%/bs4/__pycache__/dammit.cpython-37.pyc . . ===> Checking for items in pkg-plist which are not in STAGEDIR Error: Missing: %%PYTHON_SITELIBDIR%%/bs4/__pycache__/__init__.opt-1.pyc Error: Missing: %%PYTHON_SITELIBDIR%%/bs4/__pycache__/__init__.pyc Error: Missing: %%PYTHON_SITELIBDIR%%/bs4/__pycache__/css.opt-1.pyc Error: Missing: %%PYTHON_SITELIBDIR%%/bs4/__pycache__/css.pyc Error: Missing: %%PYTHON_SITELIBDIR%%/bs4/__pycache__/dammit.opt-1.pyc Error: Missing: %%PYTHON_SITELIBDIR%%/bs4/__pycache__/dammit.pyc . . PYTHON_EXT_SUFFIX as defined in Mk/Uses/python.mk is empty for ${PYTHON_REL} < 30807
It seems that PYTHON_EXT_SUFFIX is appropriate for .so files but not for byte code files. py-beautifulsoup is not the only port with this problem.
Created attachment 241727 [details] [patch] fix plist issues - v1: adjust PORTNAME, use autoplist Attached is a patch to fix the plist issues for py37. Except for the PKGNAME, this patch should result in no difference for the python flavors of py-beautifulsoup that do package successfully (py38+). See [[1]] for a way that touches python.mk but does not change the PKGNAME. - change PORTNAME to match project name (beautifulsoup -> beautifulsoup4) - because of that change: - the custom DISTNAME can be removed [[1]] - custom do-build & do-install can be removed - autoplist can be used and the static pkg-plist can be removed - 57 other ports have to change the *DEPENDS to reflect the new PKGNAME Since pkg-plist is now gone with this patch, the problematic usage of PYTHON_EXT_SUFFIX for byte code files is gone (at least for this port - there are still other ports that are using it for byte code files instead of just .so files as originally intended). Another option - query for python project name: To get the right project name (to get the right wheel filename), we could also query the pyproject.toml file for pep517 instead of the current definition of PEP517_INSTALL_CMD in python.mk. Like so (ref https://stackoverflow.com/questions/75373164/is-there-something-like-python-setup-py-version-for-pyproject-toml): python -c "import build.util; print(build.util.project_wheel_metadata('.').get('Name'))" But running that query just to get the wheel name is somewhat slow. Unless that can be queried during another existing invocation of python, I would prefer not doing that by default. [[1]] Mk/Uses/python.mk uses PORTNAME to derive the name of the wheel file. There's a case to be made that it should use DISTNAME instead (in that case the PORTNAME change in this patch is not needed and the customized DISTNAME would stay). Then the PKGNAME does not change. Orthogonally, python.mk could also make it easier to override the default wheel filename (used in PEP517_INSTALL_CMD).
Created attachment 241728 [details] [patch] fix plist issues - v2: allow alternate wheel name for pep517, use autoplist This patch is an alternate option. It uses the method described in the [[1]] footnote in comment 2. Specifically, it adds a PEP517_DISTNAME to python.mk that defaults to the same base name used in PEP517_INSTALL_CMD and in the file argument for strip-RECORD.py in the PEP517 do-install. There's no PKGNAME change here, so this doesn't affect other ports. Maybe it could be argued that the PORTNAME should match the wheel name (beautifulsoup4), but this version of the patch lives with the PORTNAME as is without the '4' suffix. So comparing to the v1 patch, it doesn't touch 57 other ports, but it does touch python.mk in order to use the targets defined there in python.mk without rolling a custom version of do-build and do-install.
There could be another alternate version that uses python to query pyproject.toml for the name (as shown in comment 2). Then wheel name could be decoupled from the PORTNAME. If one could come up with a patch that did that query without the extra penalty of forking another python command, I think that would be best. But I don't yet have a patch that does that. A patch which did that name query would also be a change to python.mk
(In reply to John Hein from comment #4) Thank you ! I shall test it in one or two days. wen
The first patch will cause build error since there is no www/py-beautifulsoup4 port. The second patch modify python.mk, we shall ask for a exp-run before commit it. wen
(In reply to Wen Heping from comment #6) Regarding the first patch... my mistake (bad sed(1)). I meant to change the package name in the DEPENDS lines (not the port origin directory) - like the following for all the dependent ports: --- a/www/py-wagtail/Makefile +++ b/www/py-wagtail/Makefile @@ -14,7 +14,7 @@ LICENSE= BSD3CLAUSE LICENSE_FILE= ${WRKSRC}/LICENSE RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}anyascii>=0.1.5:textproc/py-anyascii@${PY_FLAVOR} \ - ${PYTHON_PKGNAMEPREFIX}beautifulsoup>=4.8<4.13:www/py-beautifulsoup@${PY_FLAVOR} \ + ${PYTHON_PKGNAMEPREFIX}beautifulsoup4>=4.8<4.13:www/py-beautifulsoup@${PY_FLAVOR} \ ${PYTHON_PKGNAMEPREFIX}django32>=3.2<4.2:www/py-django32@${PY_FLAVOR} \ ${PYTHON_PKGNAMEPREFIX}django-filter>=2.2<23:www/py-django-filter@${PY_FLAVOR} \ ${PYTHON_PKGNAMEPREFIX}django-modelcluster>=6.0<7.0:www/py-django-modelcluster@${PY_FLAVOR} \ I fixed the sed, and I'm doing a bulk poudriere run for the affected ports (it'll take a while since it is building rust and gcc ports). I don't have a strong preference for either v1 or v2 of the patch at the moment. But doing an exp-run for v2 sounds fine. The python.mk change is simple enough. Maybe some other @python people may want to weigh in on that change, however. Maybe I'll open a review for that just to get some feedback.