Objection to restoring deprecated Python subports
devans at macports.org
Mon Oct 17 23:43:13 PDT 2016
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.
> 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
> 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.
> macports-dev mailing list
> macports-dev at lists.macosforge.org
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
More information about the macports-dev