> On Oct 18, 2019, at 9:02 AM, Stuart Henderson <s...@spacehopper.org> wrote:
>
> On 2019/10/17 22:27, Daniel Dickman wrote:
>>> 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.
>
> 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?)
Yes exactly. And also dealing with the top level Makefiles and quirks.
Let me try to do a proof of concept both ways using scipy and seaborn and come
back to you. Maybe it will help make things clearer (at least for 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.
Agree on consistency. That would be very useful.
No opinion on python2 though as I don’t use anything that’s python2 myself
anymore. :-)
>
>
>> 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.
