Re: Objection to restoring deprecated Python subports

2016-10-20 Thread Peter Danecek 

> On 18 Oct 2016, at 06:47, 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.
> 

+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

Re: Objection to restoring deprecated Python subports

2016-10-18 Thread Sean Farley 
Lawrence Velázquez  writes:

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

I wholeheartedly agree.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Objection to restoring deprecated Python subports

2016-10-18 Thread mf2k 

> On Oct 18, 2016, at 12:43 AM, David Evans  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@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


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

Re: Objection to restoring deprecated Python subports

2016-10-18 Thread Ryan Schmidt 

> On Oct 18, 2016, at 3:04 AM, Andrea D'Amore  wrote:
> 
> Should less-maintained ports be removed as it's being suggested
> for old python versions?

I don't have an opinion about the python ports right now. But in general, no, 
just because a port is unmaintained, or is old, or does not build on some or 
all platforms, does not automatically mean it should be removed.

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

Re: Objection to restoring deprecated Python subports

2016-10-18 Thread Andrea D'Amore 
On 18 October 2016 at 08:43, David Evans  wrote:
> 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.

IIRC there was a policy of "as long as it builds it can stay in port tree".

This seems to raise a question about obligations towards users: given
this is a best-effort project should "old" ports be removed in order
to avoid the burden of supporting them?
The "burden" here takes into account ticket managing as well.


Such a topic then widens towards less known, nomaintainer ports, who
at times have tickets floating around for months -I'd say for years as
I seem to recall one or two cases I stumbled on but I'm not sure about
it. Should less-maintained ports be removed as it's being suggested
for old python versions?
If so what draws the line, upstream support?

Would it be advisable to formalize such policy in a specific file?


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

Objection to restoring deprecated Python subports

2016-10-17 Thread Lawrence Velázquez 
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@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev