Objection to restoring deprecated Python subports

[mf2k at macports.org]

> On Oct 18, 2016, at 12:43 AM, David Evans <devans at macports.org> wrote:
> 
> On 10/17/16 9:47 PM, Lawrence Velázquez wrote:
>> Fred Wright recently opened several tickets that suggest restoring
>> several Python subports that were deprecated and moved to the Python
>> graveyard a long time ago.
>> 
>> https://trac.macports.org/ticket/52636
>> https://trac.macports.org/ticket/52637
>> https://trac.macports.org/ticket/52638
>> https://trac.macports.org/ticket/52639
>> https://trac.macports.org/ticket/52640
>> https://trac.macports.org/ticket/52641
>> https://trac.macports.org/ticket/52642
>> 
>> I strenuously object to these proposals.
>> 
>> A few years ago, I proposed a Python subport/variant policy to reduce
>> project-wide support load. That policy was that we should only provide
>> subports for the two most recent Python versions on each of the 2.x and
>> 3.x branches (modulo some details about termination of upstream
>> support).
>> 
>> Thanks to the efforts of many contributors, that proposal has been
>> mostly carried out. We absolutely should not be going backwards on this.
>> 
>> Users who wish to work with unsupported versions of Python should use
>> virtualenv to create a contained environment in which they may use the
>> bundled pip, setuptools, and wheel to install any modules they please.
>> The deprecated subports would have to be restored to the virtualenv and
>> setuptools ports; I'd be fine with this.
>> 
>> vq
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-dev
>> 
> 
> +1
> 
> My understanding is that the current target set is py27 py34 py35 with py36 on the horizon.  Earlier versions
> are problematic/unsupported upstream. And as usual people who want to build old versions
> of ports and maintain them for themselves are always able to do that. But by doing so
> they give up support from the mainstream MacPorts community.
> 
> BTW, why aren't we removing the outdated python24 python25 python26 python31 python32 python33 ports?
> Leaving these around just encourages proposals to regress back to these relics.
> 
> I propose that the tickets cited above be closed as "won't fix" due to conflict with MacPorts policy
> and that we (maintainers with commit privileges) put in a few extra ergs to clean up the remaining
> old cruft.

+1

We should not be supporting things that upstream does not support and that have replacements. The same is true for perl, apache, php, etc. This is a security issue as well as a buildbot bloat issue. 


Cheers!
Frank