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
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
of ports and maintain them for themselves are always able to do that. But by
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
macports-dev mailing list