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.
sthen