python.mk: Support PEP440 versioning
ClosedPublic
Actions

Authored by matthew on Mar 16 2023, 4:17 PM.

Details

Reviewers

Group Reviewers

portmgr
Python

Commits

R11:2b7d76adec17: Mk/Uses/python.mk: Support PEP440 versioning

Summary

The python PEP440 version numbering standard is _mostly_ compatible
with FreeBSD port versioning rules. Exceptions exist, where the
PORTVERSION can be derived from the upstream DISTVERSION
automatically. For example:

PEP440 DISTVERSION: FreeBSD PORTVERSION:
2.3.post1 2.3.p1

Now, this interacts badly with PEP517 build setups. hatchling will
enforce PEP440 complicance, so it isn't practical to modify the ported
code to use exactly the FreeBSD version.

Instead, simply referring to DISTVERSION rather than PORTVERSION will
allow the build process to complete smoothly.

See https://reviews.freebsd.org/D39123 for an example port update
which depends on this change

Diff Detail

Repository

R11 FreeBSD ports repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

matthew created this revision.Mar 16 2023, 4:17 PM

Herald added a reviewer: portmgr. · View Herald TranscriptMar 16 2023, 4:17 PM

Herald added a subscriber: mat. · View Herald Transcript

matthew requested review of this revision.Mar 16 2023, 4:17 PM

Harbormaster completed remote builds in B50419: Diff 118924.Mar 16 2023, 4:17 PM

matthew added reviewers: Python, vishwin.Mar 16 2023, 4:18 PM

Haha beat me to it! Also had this sitting locally, checking that existing PORTREVISION uses didn't break (all good there).

Current upstream setuptools also strictly enforces PEP-440. Since their scheme recognises .postN, we may need to correspondingly change pkg's version handling to account, as currently it registers as <.

vishwin accepted this revision.Mar 16 2023, 5:39 PM

In D39124#890572, @vishwin wrote:

Haha beat me to it! Also had this sitting locally, checking that existing PORTREVISION uses didn't break (all good there).

Yup. If DISTVERSION isn't defined in the port Makefile then it just gets set to PORTVERSION, so this should be a do-nothing change most of
the time. Probably going to need an exp-run just to make sure though.

Current upstream setuptools also strictly enforces PEP-440. Since their scheme recognises .postN, we may need to correspondingly change pkg's version handling to account, as currently it registers as <.

I don't think any changes to pkg(8) would be needed. The version number pkg deals with only has to exist within the pkg metadata -- there's
no requirement to modify any of the paths or filenames or other internal references to a version number within the package itself. So we can
just use the upstream build system without intrusive changes, but tag the result in a way that works with pkg's version ordering requirements.

matthew mentioned this in D39123: textproc/py-bracex: update to 2.3.p1.Mar 16 2023, 6:01 PM

matthew added a child revision: D39123: textproc/py-bracex: update to 2.3.p1.

We're safe, no exp-run needed:

% git grep -B 5 PORTVERSION= -- `git grep --max-depth=2 -l pep517`
CHANGES-  with EXTRACT_ONLY.
CHANGES-
CHANGES-  A simple example:
CHANGES-
CHANGES-    PORTNAME=     bar
CHANGES:    PORTVERSION=  1.0
--
databases/py-aiosqlite/Makefile-PORTNAME=       aiosqlite
databases/py-aiosqlite/Makefile:PORTVERSION=    0.18.0
--
devel/mercurial/Makefile-PORTNAME=      mercurial
devel/mercurial/Makefile:PORTVERSION=   6.3.2
--
devel/nox/Makefile-PORTNAME=    nox
devel/nox/Makefile:PORTVERSION= 2022.11.21
--
devel/py-RPyC/Makefile-PORTNAME=        rpyc
devel/py-RPyC/Makefile:PORTVERSION=     5.3.1
--
devel/py-argh/Makefile-PORTNAME=        argh
devel/py-argh/Makefile:PORTVERSION=     0.28.1
--
devel/py-build/Makefile-PORTNAME=       build
devel/py-build/Makefile:PORTVERSION=    0.10.0
--
devel/py-find-libpython/Makefile-PORTNAME=      find-libpython
devel/py-find-libpython/Makefile:PORTVERSION=   0.3.0
--
devel/py-flit-core/Makefile-PORTNAME=   flit-core
devel/py-flit-core/Makefile:PORTVERSION=        3.8.0
--
devel/py-flit/Makefile-PORTNAME=        flit
devel/py-flit/Makefile:PORTVERSION=     3.8.0
--
devel/py-installer/Makefile-PORTNAME=   installer
devel/py-installer/Makefile:PORTVERSION=        0.6.0
--
devel/py-interface-meta/Makefile-PORTNAME=      interface-meta
devel/py-interface-meta/Makefile:PORTVERSION=   1.3.0
--
devel/py-jsonschema/Makefile-PORTNAME=  jsonschema
devel/py-jsonschema/Makefile:PORTVERSION=       4.17.3
--
devel/py-lazy_loader/Makefile-PORTNAME= lazy_loader
devel/py-lazy_loader/Makefile:PORTVERSION=      0.1
--
devel/py-packaging/Makefile-PORTNAME=   packaging
devel/py-packaging/Makefile:PORTVERSION=        23.0
--
devel/py-pathspec/Makefile-PORTNAME=    pathspec
devel/py-pathspec/Makefile:PORTVERSION= 0.11.1
--
devel/py-pdm-pep517/Makefile-PORTNAME=  pdm-pep517
devel/py-pdm-pep517/Makefile:PORTVERSION=       1.1.0
--
devel/py-pdm/Makefile-PORTNAME= pdm
devel/py-pdm/Makefile:PORTVERSION=      2.2.1
--
devel/py-pep517/Makefile-PORTNAME=      pep517
devel/py-pep517/Makefile:PORTVERSION=   0.13.0
--
devel/py-pyls-black/Makefile-PORTNAME=  pyls-black
devel/py-pyls-black/Makefile:PORTVERSION=       0.4.7
--
devel/py-pyproject_hooks/Makefile-PORTNAME=     pyproject_hooks
devel/py-pyproject_hooks/Makefile:PORTVERSION=  1.0.0
--
devel/py-pytest-metadata/Makefile-PORTNAME=     pytest-metadata
devel/py-pytest-metadata/Makefile:PORTVERSION=  2.0.4
--
devel/py-pytoolconfig/Makefile-PORTNAME=        pytoolconfig
devel/py-pytoolconfig/Makefile:PORTVERSION=     1.2.5
--
devel/py-requirementslib/Makefile-PORTNAME=     requirementslib
devel/py-requirementslib/Makefile:PORTVERSION=  2.2.3
--
devel/py-typing-extensions/Makefile-PORTNAME=   typing-extensions
devel/py-typing-extensions/Makefile:PORTVERSION=        4.4.0
--
devel/py-virtualenv/Makefile-PORTNAME=  virtualenv
devel/py-virtualenv/Makefile:PORTVERSION=       20.20.0
--
finance/py-financedatabase/Makefile-PORTNAME=   financedatabase
finance/py-financedatabase/Makefile:PORTVERSION=        2.0.9
--
print/py-pydyf/Makefile-PORTNAME=       pydyf
print/py-pydyf/Makefile:PORTVERSION=    0.5.0
--
print/py-weasyprint/Makefile-PORTNAME=  weasyprint
print/py-weasyprint/Makefile:PORTVERSION=       58.0
--
security/py-securesystemslib/Makefile-PORTNAME= securesystemslib
security/py-securesystemslib/Makefile:PORTVERSION=      0.26.0
--
security/py-tuf/Makefile-PORTNAME=      tuf
security/py-tuf/Makefile:PORTVERSION=   2.1.0
--
sysutils/py-docker/Makefile-PORTNAME=   docker
sysutils/py-docker/Makefile:PORTVERSION=        6.0.1
--
textproc/py-pyphen/Makefile-PORTNAME=   pyphen
textproc/py-pyphen/Makefile:PORTVERSION=        0.13.0
--
textproc/py-sphinx/Makefile-PORTNAME=   sphinx
textproc/py-sphinx/Makefile:PORTVERSION=        5.3.0
--
textproc/py-tomli/Makefile-PORTNAME=    tomli
textproc/py-tomli/Makefile:PORTVERSION= 2.0.1
--
www/py-dj40-django-auth-ldap/Makefile-PORTNAME= django-auth-ldap
www/py-dj40-django-auth-ldap/Makefile:PORTVERSION=      4.1.0
--
www/py-dj41-django-auth-ldap/Makefile-PORTNAME= django-auth-ldap
www/py-dj41-django-auth-ldap/Makefile:PORTVERSION=      4.1.0
--
www/py-dj41-django-cors-headers/Makefile-PORTNAME=      django-cors-headers
www/py-dj41-django-cors-headers/Makefile:PORTVERSION=   3.14.0
--
www/py-dj41-django-rich/Makefile-PORTNAME=      django-rich
www/py-dj41-django-rich/Makefile:PORTVERSION=   1.5.0
--
www/py-django-auth-ldap/Makefile-PORTNAME=      django-auth-ldap
www/py-django-auth-ldap/Makefile:PORTVERSION=   4.1.0
--
www/py-fastapi/Makefile-PORTNAME=       fastapi
www/py-fastapi/Makefile:PORTVERSION=    0.92.0

In D39124#890579, @matthew wrote:

I don't think any changes to pkg(8) would be needed. The version number pkg deals with only has to exist within the pkg metadata -- there's
no requirement to modify any of the paths or filenames or other internal references to a version number within the package itself. So we can
just use the upstream build system without intrusive changes, but tag the result in a way that works with pkg's version ordering requirements.

Yeah, on second thought and look at bsd.port.mk, just finagling the DISTVERSION to PORTVERSION conversion regex here for the USE_PYTHON=distutils and USE_PYTHON=pep517 cases to account for postN (and others) may do it. But that's for another review.