On 2019/10/17 22:27, Daniel Dickman wrote:
> On Thu, Sep 26, 2019 at 8:25 AM Stuart Henderson <[email protected]>
> wrote:
>
> > On 2019/09/26 08:12, Daniel Dickman wrote:
> > > (Moved from: “Adding binary renaming facility to python.port.mk”)
> > >
> > > > On Sep 25, 2019, at 5:47 AM, Stuart Henderson <[email protected]>
> > wrote:
> > > >
> > > > imo, if there's a good reason to keep the py2 version (used by
> > something
> > > > else in the ports tree, or possibly if it includes a useful compiled
> > > > iextension) then split the port.
> > > >
> > > > but if the py2 version isn't really useful and is holding back an
> > update,
> > > > drop the py2 version.
> > >
> > > I’m wondering how you’re thinking about this. Something like the below?
> > >
> > > Change:
> > >
> > > FLAVORS = python3
> > > FLAVOR ?=
> > >
> > > To:
> > >
> > > FLAVORS = python3
> > > FLAVOR = python3
> > >
> > > (Note, I purposely remove the ? above to avoid ability to override
> > FLAVOR.)
> > >
> > > I think this approach would minimize changes in reverse dependencies
> > that depend on a FLAVOR.
> >
> > For the sake of consistency I was mostly thinking of following the
> > current py3-only ports and use MODPY_VERSION=${MODPY_DEFAULT_VERSION_3}
> > without a flavour, it's not too much work to find and update reverse
> > dep's.
> >
> > I had originally tried this approach via MODPY_VERSION and found it
> painful as a transition strategy compared to my proposed approach via
> FLAVOR/S.
Painful in what way?
It is a bit awkward later because then you have a mixture of
${MODPY_FLAVOR} for the dual-version ports and no ${MODPY_FLAVOR} for
others but that is the current standard approach in ports (and the
actual transition seems alright to me?)
Reminder that I would still like to convert things so that py2 things
are *also* flavoured, i.e. FLAVOR=python2/python3 or maybe py27/py37/py38/etc,
but I see that as a separate step to what you're doing here [I'm
considering looking at this at p2k19]. It's easier to do that if all
of the existing py3-only ports are consistent with respect to each other.
> So I think maybe better to keep all the ,python3 flavors first, then when
> we’re ready to drop python2 do a bulk conversion of the tree to drop those
> flavors?
>
> But I’m open to ideas if someone has a good strategy they can share.
>
> Would be nice to decide on the approach because I have my python3-only,
> numpy 1.17.3 update pretty much ready to go. And that port is going to have
> an impact on a good chunk of the ports tree...
>
> ps. I suggest scipy, matplotlib or pandas as proof of concept ports to
> update because: they’re probably some of the most widely used python ports,
> have all gone python3-only, and have fewer reverse dependencies to worry
> about.
