Objection to restoring deprecated Python subports

[Peter Danecek]

> On 18 Oct 2016, at 06:47, Lawrence Velázquez <larryv at macports.org> 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.
> 

+1

I think we most arguments were already expressed. There policy on this was proposed already some years back and largely agreed on. I do not see why his should now change again. 

There is also a fundamental reason not to support python26: We usually support only one version per module and often with updates upstream drops support, so we had to remove support as well if we do not want to generate too much maintenance overhead (multiple version conditions etc.). This however might cause python ports loosing their dependencies and create mess, broken ports, tickets, etc.

> 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).

However, I think in the current situation there is a good point in support the following *three* versions py27, py34 **and** py35. Supporting two Py3 versions does not seem to creates much maintenance overhead and it gives and the users do a “rolling” update. I guess once py26 subports have all be removed and we have a decent set of py36 subparts added, we probably have set a policy wrt. py34.


> 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.

On the other hand, there is a good reason to keep also older interpreters (e.g. python26, python33) around exactly for this reason. This gives users a quite immediate possibility to setup a (set of) virtualenv and multiple Python packages version for testing.

~petr