On Thu, Feb 20, 2020 at 01:55:00PM +0000, Stuart Henderson wrote:
> Quite a few python modules are now py3-only, and more are switching
> over to that. The current ports setup where we use MODPY_VERSION=
> ${MODPY_DEFAULT_VERSION_3} and no FLAVOR isn't really very good,
> especially where dependencies are concerned with the error-prone
> combination of "py2+3 ports using ${MODPY_FLAVOR}" and "py3-only
> ports with just the port path/name".
> Before more are moved across I'd like to settle on a proper method.
> I've been discussing this with jasper@ (with some previous knowledge
> from adding a similar multi-version to pecl-* ports) and propose moving
> to a setup with:
> FLAVOR= python3
> FLAVORS= python3
> (and keep the ,python3 flavour in ../Makefile i.e. "SUBDIR +=
> py-Foo,python3").
> This also makes it easier to handle updates as we don't need to mess about
> with @pkgpath markers.
I like this very much. Simple. It makes it obvious and feels less like
stepping on rakes like the current scheme does. (Putting the obvious
MODPY_FLAVOR after a depends and having it fil and needing to figure out
why).
(More below)
> Just merge py-foo into py3-foo automatically.
> This was done with some py3 conversions in the past:
> files/Quirks.pm: 'py-nmap' => 'py3-nmap',
> files/Quirks.pm: 'py-link-grammar' => 'py3-link-grammar',
> files/Quirks.pm: 'py-buildbot-www' => 'py3-buildbot-www',
> files/Quirks.pm: 'py-buildbot-pkg' => 'py3-buildbot-pkg',
> files/Quirks.pm: 'py-buildbot-grid-view' => 'py3-buildbot-grid-view',
> files/Quirks.pm: 'py-buildbot-console-view' =>
> 'py3-buildbot-console-view',
> files/Quirks.pm: 'py-buildbot-waterfall-view' =>
> 'py3-buildbot-waterfall-view',
> files/Quirks.pm: 'py-pafy' => 'py3-pafy',
> files/Quirks.pm: 'py-zeroconf' => 'py3-zeroconf',
> files/Quirks.pm: 'py-xmldiff' => 'py3-xmldiff',
Much better.
> In cases where there are bin/ scripts where the py2 version will
> have a hard conflict with the py3 version it *has* to be done this way.
> In other cases there is a possible alternative: list in
> $obsolete_reasons and have the user manually delete the py2 version if
> they don't want it. This has been done for some ports more recently
> (e.g. py-semver) but I don't think we should generally continue with it.
> Admittedly it *is* more friendly to an user writing their own py2
> scripts using modules from ports, but the common use case for packages
> is a standard package user who just has things installed as a dependency
> of something else. In that case after a pkg_add -u they get e.g.
> Obsolete package: py-semver-2.8.1p0 (python2 port superseded by python3
> version)
> : FLAVORS = python3
> : -FLAVOR ?=
> : +FLAVOR = python3
> Just hardcode the flavour here so "make" directly in the port dir works
> sanely. Note this means that MODPY_VERSION=${MODPY_DEFAULT_VERSION_3} is
> not required.
This is much friendlier to do. The existing scheme was non-obvious.
> : diff -u -p -r1.8 PLIST
> : --- net/py-netmiko/pkg/PLIST 13 Nov 2019 20:13:39 -0000 1.8
> : +++ net/py-netmiko/pkg/PLIST 12 Feb 2020 19:14:28 -0000
> : @@ -1,4 +1,6 @@
> : @comment $OpenBSD: PLIST,v 1.8 2019/11/13 20:13:39 jasper Exp $
> : +@conflict py-netmiko-*
> : +@pkgpath net/py-netmiko
> Works with the quirks changes above to allow automatically replacing
> py-netmiko with py3-netmiko.
> In this particular case there aren't really conflicting files but I think
> it makes sense to do that as standard (in cases where there are scripts in
> bin/ without a suffix then there would be a conflict - easier to just
> always include it so people looking for examples to crib from have an
> easier time).
Yes. I agree.
> Obviously there are currently a number of py3-only ports which should end
> up using the same flavour scheme (and dependency lines to fix), if there are
> not objections I can either review diffs or take care of those myself.
No objections here.
> There is a possible future direction I've been considering of moving py2
> ports from "unflavoured" to "FLAVOR=python2" (and possibly splitting
> python3 into multiple versions e.g. python37/python38 as we do with ruby).
> I'm unsure if it's worthwhile at the moment, but this method of converting
> to py3-only at least doesn't get in the way of doing that later.
I like the FLAVOR=python2. I'm a little wary of the python37/python38
thing. It will introduce a *lot* of churn each time we introduce a
new python 3.x version to the tree or when we retire one.
--Kurt
