Created attachment 253990 [details] devel/py-Automat: Update to 24.8.1 Changelog ========= * Update to 24.8.1 * Convert to PEP-517 * Note: 24.8 introduces a major change to the public API, `TypeMachineBuilder, while retaining `MethodicalMachine` for backward compatibility. See the documentation for details. QA == portlint: OK poudriere: OK -- testport on 14.1R on amd64 w/py38, py39, py310, and py311 (default)
Comment on attachment 253990 [details] devel/py-Automat: Update to 24.8.1 Use DISTVERSION instead of PORTVERSION. Set "maintainer-approval" flag for patch.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=bb19a6db5199329fac53aa72770ad64f74f0acf8 commit bb19a6db5199329fac53aa72770ad64f74f0acf8 Author: John W. O'Brien <john@saltant.com> AuthorDate: 2024-10-05 22:57:06 +0000 Commit: Vladimir Druzenko <vvd@FreeBSD.org> CommitDate: 2024-10-05 22:57:06 +0000 devel/py-Automat: Update 22.10.0 → 24.8.1 Commit log: https://github.com/glyph/automat/compare/v22.10.0...v24.8.1 - Convert to PEP-517 - Note: 24.8 introduces a major change to the public API, `TypeMachineBuilder`, while retaining `MethodicalMachine` for backward compatibility. See the documentation for details. PR: 281847 devel/py-Automat/Makefile | 24 ++++++++++++++---------- devel/py-Automat/distinfo | 8 +++----- devel/py-Automat/pkg-message | 2 +- 3 files changed, 18 insertions(+), 16 deletions(-)
Thanks.
(In reply to Vladimir Druzenko from comment #1) Thank you for taking this PR and committing the patch. As for PORTVERSION vs. DISTVERSION, I don't understand why you changed this. I didn't choose arbitrarily. I tried to interpret applicable information. -- What does bsd.port.mk say? ... # PORTVERSION - Version of software. Mandatory when no DISTVERSION is given. ... # DISTVERSION - Vendor version of the distribution. # Default: ${PORTVERSION} ... While this is ambiguous, b.p.m lists PORTVERSION second overall, just after PORTNAME, and DISTVERSION defaults to PORTVERSION while there is no stated default for PORTVERSION. Both of these imply that PORTVERSION is the primary designation, and that there may be a minority of cases in which DISTVERSION needs to be overridden or used instead of PORTVERSION. I cannot recall a case with any port I have ever touched when setting PORTVERSION resulted in an undesired outcome. -- What do people actually use? % find /usr/ports/ -depth 3 -name Makefile \ | xargs grep -Eoh "^(PORT|DIST)VERSION=" \ | sort \ | uniq -c \ | sort -rn 22486 PORTVERSION= 9024 DISTVERSION= % find /usr/ports/ -depth 3 -name Makefile \ | xargs grep -Eh "^DISTNAME=" \ | grep -Eo "(PORT|DIST)VERSION" \ | sort \ | uniq -c \ | sort -rn 2488 PORTVERSION 1122 DISTVERSION The use of PORTVERSION is more than twice as frequent than DISTVERSION, in both of the cases you changed. -- What do people discuss? In my email archive of the freebsd-ports list back to 2013, I looked at all the threads mentioning PORTVERSION or DISTVERSION in the subject, and found only mentions of using PORTVERSION or of solving a problem by using DISTVERSION. So, why should a port use DISTVERSION instead of PORTVERSION?
(In reply to John W. O'Brien from comment #4) Use PORTVERSION only if ports framework doesn't support versioning scheme of a software: https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-versions There is a gradual migration from PORTVERSION to DISTVERSION in ports.
(In reply to Vladimir Druzenko from comment #5) That's very helpful. Thank you. How are port maintainers expected to discover this?
(In reply to John W. O'Brien from comment #6) Sorry, I don't have an answer to this question…
(In reply to John W. O'Brien from comment #0) (In reply to commit-hook from comment #2) May I ask why you use py-setuptools_scm7 rather than py-setuptools-scm? Does setuptools-scm 8.x lead to a breakage?
(In reply to Po-Chuan Hsieh from comment #8) Ha! I retained the py-setuptools_scm7 dependency because I looked to see if there was a more recent version like this: % ls -d /usr/ports/*/py-setuptools_scm* Now I see that the current version is devel/py-setuptools-scm with a dash. This is the only port I maintain that depends on setuptools-scm. Thanks for the gentle thwap with the clue stick.
(In reply to John W. O'Brien from comment #9) Yes, it causes some breakage, at least on my poudriere builder. py38 and py39: devel/py-setuptools-scm fails during build with AttributeError: 'PathDistribution' object has no attribute '_normalized_name' py310 and py311: build appears to work
Created attachment 254100 [details] Poudriere log excerpt for devel/py-setuptools-scm This poudriere log excerpt shows the full error during the build phase of devel/py-setuptools-scm against py39. The py38 error is essentially identical, though I expect there will be no interest in py38 since its remaining time in the ports tree may is so short.
(In reply to John W. O'Brien from comment #10) See also bug 281823 comment 3 and bug 281823 comment 9. Same issue after py-incremental was updated recently including a change to pep517 building. py-setuptools-scm@py39 built fine about six weeks ago. I haven't identified what dependency has changed to break since then. It could be that updating py-setuptools from the old 63.1.0 to a newer version will help in a number of breakage cases like this one, but it's slow in coming for various logjam reasons (bug 270358).
(In reply to John Hein from comment #12) > py-setuptools-scm@py39 built fine about six weeks ago. I haven't > identified what dependency has changed to break since then. It looks like the update to py-pyproject_hooks (1.1.0 -> 1.1.0_1) might be the culprit for this "no attribute '_normalized_name'" problem with py38/py39.
(In reply to Po-Chuan Hsieh from comment #8) I suggest you close this bug because the update to 24.8.1 was successfully committed without breakage. Then open a new one to update devel/py-Automat's DEPENDS from py-setuptools_scm7 to py-setuptools-scm, which could then be blocked on the build failure of py-setuptools-scm (such as bug #278299).
See bug #284044.