allows some additional debugging features for Python-based software
(for example there's a new "py-bt" command to print a Python backtrace
which can give clues if a py process is hanging).
ok rpointel@
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.
While waiting for this to appear in a proper Python 3.9.x release,
use upstream's commit for this severe sprintf bug.
The bug was reported on Jan 16 and the fix was available since Jan 18,
but only 3.6 and 3.7 have new releases as of now.
ok sthen
While waiting for this to appear in a proper Python 3.8.x release,
use upstream's commit for this severe sprintf bug.
The bug was reported on Jan 16 and the fix was available since Jan 18,
but only 3.6 and 3.7 have new releases as of now.
ok sthen
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@
An earlier diff was okayed by rpointel@, kmos@. sthen@ requested to move
the @conflict and @pkgpath markers from 3.7 to 3.8 in the same commit (a
better approach). Final diff was ok sthen@.
Python" messages, Python 2 development has finished so this is not a
sensible option to use as default.
(It is still kept in the ports tree for now, as some important software
has not been updated to use Python 3).
ok tracey aja mariani rpointel
From https://www.python.org/doc/sunset-python-2/, "We are volunteers who
make and take care of the Python programming language. We have decided
that January 1, 2020, was the day that we sunset Python 2. That means
that we will not improve it anymore after that day, even if someone
finds a security problem in it. You should upgrade to Python 3 as soon
as you can."
already run into it myself. Add comments to hopefully make it simpler
and more understandable for future changes to the default version.
Zero feedback but tests well here, committing before I forget about
it because people will run into this with 6.7.
