astro/py-metpy requires math/py-numpy 1.16.0

With hat:	portmgr

devel/py-clikit requires devel/py-enum34 between 1.1 and 2.0 (>=1.1,<2.0)

and graphics/py-pillow6

With hat:	portmgr

With hat:	portmgr
Differential Revision:	https://reviews.freebsd.org/D23757

science/py-geometer requires math/py-numpy between 1.15 and 1.19 (>=1.15,<1.19)

devel/py-xarray requires math/py-numpy 1.15

devel/py-glance-store requires devel/py-enum34 1.0.4.

With hat:	portmgr

mail/py-mail-parser requires net/py-ipaddress 1.0.23

Much of the Python version selection code had compat shims around to
accomodate the transition from before to with flavors. These can now be
removed.

PR:		243185
Reviewed by:	antoine
Differential Revision:	https://reviews.freebsd.org/D23084

This was used before flavors were a thing to make sure if you built port
A with some python version, and it needed port B, port B would also be
built with the same python version.

PR:		243185
Reviewed by:	antoine
Differential Revision:	https://reviews.freebsd.org/D23084

With hat:	portmgr
PR:		233770

With hat:	portmgr

PR:		241416
Submitted by:	wen@(myself)
Reviewed by:	koobs@, amdmi3@

devel/py-typing-extensions requires py-typing 3.7.4+.

Make it clear that <version-spec> is a declarative not imperative
specification to declare what version of Python a port or software
*supports*, not the versions it should *use*.

The version that gets selected is a function of Python.mk, DEFAULT_VERSIONS
which change over time, and can be overridden or otherwise set by the user.

While I'm here, add a special note about bare USES=python (without a
<version-spec>), which is likely to be deprecated at some point down the
line. In the meantime, describe what the semantics of not specifying a
<version-spec> entails, and encourage minimisation of its use where
appropriate.

Approved by:	koobs (python, maintainer)

security/theonionbox requires py-futures>=3.2.

Since devel/py-promise requires 3.6.4+, the minimal version is set to 3.6.4.

With hat:	python

The deprecated comment was added in r364450 (bsd.python.mk to Uses/python.mk transition) but it is not.

With hat:	portmgr

PR:		235901
Approved by:	mat
Differential Revision:	https://reviews.freebsd.org/D19569

PR:		224024

imp.get_tag() is deprecated since version 3.4.
Use sys.implementation.cache_tag directly starting in Python 3.3.

Reference:	https://docs.python.org/3/library/imp.html#imp.get_tag

- Added python37 docs
- Added python37 support to Mk/

Reviewed by:	bapt
Approved by:	bapt (portmgr)
Differential Revision:	https://reviews.freebsd.org/D16159

PR:		227428
Exp-run by:	antoine

Changes:	http://www.boost.org/users/history/version_1_67_0.html
PR:		227427
Exp-run by:	antoine
Differential Revision:	https://reviews.freebsd.org/D15030

It's only used by 1 port (devel/py-fortran).

PR:		225752
With hat:	portmgr

this oversight.

Reviewed by:	antoine
Sponsored by:	Absolight
Differential Revision:	https://reviews.freebsd.org/D14368

Approved by:	portmgr (implicit)

phase.

Sponsored by:	Absolight

Sponsored by:	Absolight

This allows to have more complex renaming schemes.  Until now, it could
only add a prefix or a suffix, but this was not working at all for man
pages, because it would give man/man1/pyfoo.1.gz-2.7 or
man/man1/pyfoo-1-2.7.gz.  With this change, a man page will be correctly
renamed to man/man1/pyfoo-2.7.1.gz.

Unfix ports that were already handling man pages.

PR:		220214
Submitted by:	Fukang Chen (previous patch)
Exp-run by:	antoine
Sponsored by:	Absolight
Differential Revision:	https://reviews.freebsd.org/D13444

Before this, it could have been set to the current flavor of the port
that may not have been related to Python at all.

This of course never came up during development because at that time,
the only flavors were the Python flavors.

Reported by:	dbn
Sponsored by:	Absolight

Sponsored by:	Absolight