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


_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to