setuptools (it's used as a package locator but importlib.metadata in
newer Python core or the external importlib_metadata are preferred).
So drop the RDEP in that case (it's still kept for py27) and bump
revisions.
version in -stable of the previous release when plist is changed etc
(e.g. backporting updates to -stable after swotching the default
Python version during a release cycle means that -current needs
to keep ahead of -stable, to avoid problems with -stable packages
at the next release)
for those builds done via MODPY_SETUPTOOLS - I was hoping we'd get
away without it for pep517 setuptools builds but naddy ran into a
build problem with py-cryptography which seems that it can only have
happened if importlib-metadata was installed and junked at the wrong
time during build)
we _may_ need nojunk for the other pep517 backends but let's try to
avoid it if possible first.
change from substring match to equality checks so that e.g. listing multiple
backends for MODPY_PEP517 isn't allowed (AFAIK it won't be needed anyway,
it's possible to just set "yes" instead of a backend name and list the
deps in a port itself, plus it wasn't handled properly in the pile of
.elifs).
for setuptools ports with no distributed setup.py file; this suggests that
they probably ought to use MODPY_PEP517 instead so it's helpful to have
this show up in build logs.
pyproject.toml-only ports - add a comment making it clear that it was
generated by python.port.mk; makes it easier to identify where it came
from when looking at files in a port's WRKSRC
Since the non-default versions of Python now have pip executables
(in this case named bin/pip3.8) when updating from the OpenBSD version
where that file was in py3-pip, pkg_add needs to merge the updates
of the new py3-pip and python-3.8 packages. Found by sdk@ testing
7.0->-current updates. Add to the "switching default version"
checklist.
if you want to run some software that needs an older or newer version
of Python you can do so in most cases. For the default versions (2.7, 3.9)
pip is available from the separate port (devel/py2-pip, devel/py-pip).
Factor out some common parts to ../Makefile.inc while there. OK kmos@
It doesn't cover every py2 port that uses py-test, but it lets us
whittle down the number. The remaining py2 ports using py-test can then
either move to using MODPY_PYTEST (preferably) or a flavour-dependent
NO_TEST directly until we remove all use of py2 py-test and can then
update the py-test stack.
Add a new SUBST_VARS variable that is set to "@comment " on
most Python versions, but is set to "" on the default one. This makes
it easier to swap between default versions because you don't need
to figure out which @comments should be kept and which should be moved.
While there I remove some existing lines with @comment markers for
files that are not created by any of our current Python ports:
@comment bin/pyvenv
@comment lib/libpython3.8m.so (etc)
The @comment -> ${PY_DEFAULTONLY} change doesn't affect the generated
PLISTs at all, so for that a REVISION bump is unnecessary, but removing
the pyvenv/libpython3.Xm.so does require a bump
other than the usual "python3/<blank>" python version selection and
remove setting MODPY_VERSION=${MODPY_DEFAULT_VERSION_3} again from the
affected ports.
if a port needs 2.x then set MODPY_VERSION=${MODPY_DEFAULT_VERSION_2}.
This commit doesn't change any versions currently used; it may be that
some ports have MODPY_DEFAULT_VERSION_2 but don't require it, those
should be cleaned up in the course of updating ports where possible.
Python module ports providing py3-* packages should still use
FLAVOR=python3 so that we don't have a mixture of dependencies some
using ${MODPY_FLAVOR} and others not.
MODPY_BIN_ADJ's perl snippt accepts multiple files so save a few execs.
To make it more robust, also append `--' to it such that ports cannot
(accidentially) pass options; I've checked the tree that no port does
this on purpose.
The only case where this could fail is with huge MODPY_ADJ_FILES but
that is not the case in our tree; ports where lots of shebangs are
fixed have their own construct around it, e.g. textproc/calibre which
uses the `find -exec ${MODPY_ADJ_FILES} {} +' idiom.
OK sthen
setuptools picks up plugins during the configure stage whether a port
needs them or not. In some cases (currently just setuptools_scm), these
register hooks to run in the install stage; if the plugin is not a
listed build dependency this will cause the install stage to fail.
Recently reported by naddy with py-sphinx but we've seen spurious
failures elsewhere before which are likely due to this.
ok kmos@
sthen