On Thu, Sep 26, 2019 at 8:25 AM Stuart Henderson <s...@spacehopper.org>
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 <s...@spacehopper.org>
> 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.
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.
