On Fri, Sep 07, 2018 at 01:05:56PM +0100, Stuart Henderson wrote: > On 2018/09/07 01:17, Ayaka Koshibe wrote: > > Hi, > > > > Removing MODPY_DEFAULT_VERSION_2 since that seems to be preferred at this > > point in time. > > > > OK? > > > > Thanks, > > Ayaka > > > > Index: Makefile > > =================================================================== > > RCS file: /cvs/ports/net/mininet/Makefile,v > > retrieving revision 1.10 > > diff -u -p -u -r1.10 Makefile > > --- Makefile 6 Sep 2018 14:12:04 -0000 1.10 > > +++ Makefile 7 Sep 2018 08:02:05 -0000 > > @@ -21,8 +21,6 @@ MASTER_SITES = https://github.com/akoshi > > > > MODULES = lang/python > > MODPY_SETUPTOOLS = Yes > > -# Does not run with Python 3 > > -MODPY_VERSION = ${MODPY_DEFAULT_VERSION_2} > > BUILD_DEPENDS = devel/help2man > > RUN_DEPENDS = net/socat \ > > net/iperf > > > > OK sthen@ > > As suggested by jca I'll explain more - > > The reason I don't like this "python 2-only marker" is that ports may > get updated and add py3 support, but either upstream forgets to add to > changelog, or the porter doesn't notice it. Having the entry in the port > Makefile acts as a prompt that it's already been checked and is correct, > but really it might be long out of date. > > That doesn't apply so much to mininet (as you are involved with the port > and work on mininet itself I think you will notice!) but when people see > something in one part of the tree, it gets copied ... > > The time when this setting will be useful is when we switch > python.port.mk to using 3.x by default, but this will be a lot of work > in the ports tree (partly due to py2 modules being "unflavoured", partly > due to the testing needed with the versions in-tree at the time, partly > due to the whole-tree port changes/bumps needed) so I don't think it > will happen very soon, and we would need to check the whole tree when > we make that change. > > For now: I do think that where a particular "standalone" python port > offers a choice of either python 2 or 3, we should choose python 3 > unless there's a good reason not to. And that having an out-of-sync > "py2-only" marker gets in the way of this happening in the future. > > (For ports providing python modules, it usually makes sense to > provide both py2 and py3 versions).
Amen! -- Antoine
