freebsd-ports/textproc/py-wcmatch/Makefile

46 lines
1.4 KiB
Makefile
Raw Normal View History

PORTNAME= wcmatch
textproc/py-wcmatch: update to 8.4.1 The upstream package nolonger uses python setuptools, instead building a wheel using hatchling. There is no build target to install the python module directly -- the generated wheel has to be processed by pip. Indeed, with the PEP-517 support in recent versions of pip, the whole package can be built and installed in one commandline using pip. There are two approaches here: * maintain our own setup.py etc. to recreate the setuptools support from older versions -- an approach taken in textproc/py-pymdown-extensions, which is another package by the same upstream author with similar tooling. * alternatively, embrace the new python build system, using hatchling to create a python wheel and pip to install it to staging. I chose the latter, but it is trickier than it seems. pip is not really designed for installing to a staging location as required when building a port. pip options for manipulating the installation prefix (--root, --prefix) pollute the installed _pycache_ files with the staging directory path. In fact, this only works at all, because everything in this package is installed under PYTHON_SITELIBDIR and we can set the `--target` option to ${STAGING}${PYTHON_SITELIBDIR} to achive the desired effect. The PEP-517 ideal would be to use pip to build and install everything, and manage all the dependency resolution etc., but that's not compatible with port building. Fortunately, it is possible to turn off all of the unrequired functionality. It would be cleaner to implement a python module to directly convert wheels into FreeBSD pkgs, or vice-versa. Changes: https://github.com/facelessuser/wcmatch/releases/tag/8.4 Changes: https://github.com/facelessuser/wcmatch/releases/tag/8.4.1
2022-12-12 14:38:19 +01:00
PORTVERSION= 8.4.1
CATEGORIES= textproc python
MASTER_SITES= CHEESESHOP
PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}
MAINTAINER= matthew@FreeBSD.org
COMMENT= Wildcard/glob file name matcher
WWW= https://pypi.org/project/wcmatch/
LICENSE= MIT
LICENSE_FILE= ${WRKSRC}/LICENSE.md
textproc/py-wcmatch: update to 8.4.1 The upstream package nolonger uses python setuptools, instead building a wheel using hatchling. There is no build target to install the python module directly -- the generated wheel has to be processed by pip. Indeed, with the PEP-517 support in recent versions of pip, the whole package can be built and installed in one commandline using pip. There are two approaches here: * maintain our own setup.py etc. to recreate the setuptools support from older versions -- an approach taken in textproc/py-pymdown-extensions, which is another package by the same upstream author with similar tooling. * alternatively, embrace the new python build system, using hatchling to create a python wheel and pip to install it to staging. I chose the latter, but it is trickier than it seems. pip is not really designed for installing to a staging location as required when building a port. pip options for manipulating the installation prefix (--root, --prefix) pollute the installed _pycache_ files with the staging directory path. In fact, this only works at all, because everything in this package is installed under PYTHON_SITELIBDIR and we can set the `--target` option to ${STAGING}${PYTHON_SITELIBDIR} to achive the desired effect. The PEP-517 ideal would be to use pip to build and install everything, and manage all the dependency resolution etc., but that's not compatible with port building. Fortunately, it is possible to turn off all of the unrequired functionality. It would be cleaner to implement a python module to directly convert wheels into FreeBSD pkgs, or vice-versa. Changes: https://github.com/facelessuser/wcmatch/releases/tag/8.4 Changes: https://github.com/facelessuser/wcmatch/releases/tag/8.4.1
2022-12-12 14:38:19 +01:00
BUILD_DEPENDS= ${PYTHON_PKGNAMEPREFIX}hatchling>=0.21.1:devel/py-hatchling@${PY_FLAVOR} \
${PYTHON_PKGNAMEPREFIX}pip>=22.2:devel/py-pip@${PY_FLAVOR}
RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}bracex>=2.1.1:textproc/py-bracex@${PY_FLAVOR}
TEST_DEPENDS= ${PYTHON_PKGNAMEPREFIX}pytest>0:devel/py-pytest@${PY_FLAVOR} \
${PYTHON_PKGNAMEPREFIX}pytest-cov>0:devel/py-pytest-cov@${PY_FLAVOR} \
${PYTHON_PKGNAMEPREFIX}coverage>0:devel/py-coverage@${PY_FLAVOR}
textproc/py-wcmatch: update to 8.4.1 The upstream package nolonger uses python setuptools, instead building a wheel using hatchling. There is no build target to install the python module directly -- the generated wheel has to be processed by pip. Indeed, with the PEP-517 support in recent versions of pip, the whole package can be built and installed in one commandline using pip. There are two approaches here: * maintain our own setup.py etc. to recreate the setuptools support from older versions -- an approach taken in textproc/py-pymdown-extensions, which is another package by the same upstream author with similar tooling. * alternatively, embrace the new python build system, using hatchling to create a python wheel and pip to install it to staging. I chose the latter, but it is trickier than it seems. pip is not really designed for installing to a staging location as required when building a port. pip options for manipulating the installation prefix (--root, --prefix) pollute the installed _pycache_ files with the staging directory path. In fact, this only works at all, because everything in this package is installed under PYTHON_SITELIBDIR and we can set the `--target` option to ${STAGING}${PYTHON_SITELIBDIR} to achive the desired effect. The PEP-517 ideal would be to use pip to build and install everything, and manage all the dependency resolution etc., but that's not compatible with port building. Fortunately, it is possible to turn off all of the unrequired functionality. It would be cleaner to implement a python module to directly convert wheels into FreeBSD pkgs, or vice-versa. Changes: https://github.com/facelessuser/wcmatch/releases/tag/8.4 Changes: https://github.com/facelessuser/wcmatch/releases/tag/8.4.1
2022-12-12 14:38:19 +01:00
USES= python:3.7+
USE_PYTHON= flavors
# PYTHON_EXT_SUFFIX could be used here, except that it is
# special-cased for python3.7 which we don't want.
PYCACHE_SUFFIX= .cpython-${PYTHON_SUFFIX}.pyc
PLIST_SUB+= PORTVERSION=${PORTVERSION} PYCACHE_SUFFIX=${PYCACHE_SUFFIX}
NO_ARCH= yes
textproc/py-wcmatch: update to 8.4.1 The upstream package nolonger uses python setuptools, instead building a wheel using hatchling. There is no build target to install the python module directly -- the generated wheel has to be processed by pip. Indeed, with the PEP-517 support in recent versions of pip, the whole package can be built and installed in one commandline using pip. There are two approaches here: * maintain our own setup.py etc. to recreate the setuptools support from older versions -- an approach taken in textproc/py-pymdown-extensions, which is another package by the same upstream author with similar tooling. * alternatively, embrace the new python build system, using hatchling to create a python wheel and pip to install it to staging. I chose the latter, but it is trickier than it seems. pip is not really designed for installing to a staging location as required when building a port. pip options for manipulating the installation prefix (--root, --prefix) pollute the installed _pycache_ files with the staging directory path. In fact, this only works at all, because everything in this package is installed under PYTHON_SITELIBDIR and we can set the `--target` option to ${STAGING}${PYTHON_SITELIBDIR} to achive the desired effect. The PEP-517 ideal would be to use pip to build and install everything, and manage all the dependency resolution etc., but that's not compatible with port building. Fortunately, it is possible to turn off all of the unrequired functionality. It would be cleaner to implement a python module to directly convert wheels into FreeBSD pkgs, or vice-versa. Changes: https://github.com/facelessuser/wcmatch/releases/tag/8.4 Changes: https://github.com/facelessuser/wcmatch/releases/tag/8.4.1
2022-12-12 14:38:19 +01:00
do-build:
cd ${WRKSRC} && ${PYTHON_CMD} -m hatchling build -t wheel
do-install:
${PYTHON_CMD} -m pip --no-cache-dir install --no-deps --ignore-installed \
--disable-pip-version-check --target ${STAGEDIR}${PYTHON_SITELIBDIR} \
${WRKSRC}/dist/${PORTNAME}-${PORTVERSION}-py3-none-any.whl
do-test:
@(cd ${TEST_WRKSRC} && ${SETENV} ${TEST_ENV} ${PYTHON_CMD} -m pytest)
.include <bsd.port.mk>