RFC: Remove old Python versions

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Remove old Python versions

Chih-Hsuan Yen
Hi all,


I'd like to remove old Python version - python{24,25,31,32,33}. I see no
ports depend on python{31,32,33} and no one maintains them, but those
ports are still kept for while. Is there a reason for not deleting them?


Cheers,


Chih-Hsuan Yen



signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Remove old Python versions

Fred Wright

On Sun, 21 Oct 2018, Chih-Hsuan Yen wrote:

> I'd like to remove old Python version - python{24,25,31,32,33}. I see no
> ports depend on python{31,32,33} and no one maintains them, but those
> ports are still kept for while. Is there a reason for not deleting them?

Some of us like to test Python code against as many versions as possible.
It's bad enough to have to maintain locally patched versions of a few
Python-related ports just to expand the version lists, without having the
Python versions themselves disappear.

My own philosophy is never to drop anything without a sound technical
reason, rather than just being "too old".  If the same zeal for
eliminating Python versions were applied to OS versions, MacPorts wouldn't
run on anything older than 10.12.

Checking port dependents is inadequate, since it doesn't cover
"dependents" based on user interest.  If one were to remove all ports
without dependents, and iterate, there would be no ports at all. :-)

Fred Wright
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Remove old Python versions

Chih-Hsuan Yen

Fred Wright <[hidden email]> 於 2018年10月22日 週一 上午3:27寫道:
>
>
> On Sun, 21 Oct 2018, Chih-Hsuan Yen wrote:
>
> > I'd like to remove old Python version - python{24,25,31,32,33}. I see no
> > ports depend on python{31,32,33} and no one maintains them, but those
> > ports are still kept for while. Is there a reason for not deleting them?
>
> Some of us like to test Python code against as many versions as possible.
> It's bad enough to have to maintain locally patched versions of a few
> Python-related ports just to expand the version lists, without having the
> Python versions themselves disappear.
>

Hi,

Thanks for pointing out a valid reason for keeping old Python versions. I know some projects still supporting as old as Python 3.2 or 2.6. Are there examples for Python 2.5 and 3.1?

> My own philosophy is never to drop anything without a sound technical
> reason, rather than just being "too old".  If the same zeal for
> eliminating Python versions were applied to OS versions, MacPorts wouldn't
> run on anything older than 10.12.
>

Well, upgrading from old Python versions is much easier than upgrading from old OS X versions. Due to Apple policies, new OS X versions do not work on old machines, and buying a new machine is apparently not an option for some people. In contrast, upgrading from Python 2.5 to 2.7 or 3.1 to 3.4+ takes almost no cost as CPython developers keep backward compatibility as best as they can do.

Regarding "technical reasons" - there's one: old Python version does not build with OpenSSL 1.1, thus a blocker for upgrading the openssl port, and I don't think backporting fixes for openssl 1.1 is feasible as hundreds of lines should be patched.

> Checking port dependents is inadequate, since it doesn't cover
> "dependents" based on user interest.  If one were to remove all ports
> without dependents, and iterate, there would be no ports at all. :-)
>

Of course I won't even consider ports with maintainers - there's at least one user :) I wrote this letter as those old Python versions are marked as nomaintainer (except python24, which the maintainer confirms he no longer needs it), so I wonder if there are still users for them.

Regards,

Chih-Hsuan Yen

> Fred Wright
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Remove old Python versions

Chih-Hsuan Yen
Chih-Hsuan Yen <[hidden email]> 於 2018年10月24日 週三 上午11:12寫道:

>
>
> Fred Wright <[hidden email]> 於 2018年10月22日 週一 上午3:27寫道:
> >
> >
> > On Sun, 21 Oct 2018, Chih-Hsuan Yen wrote:
> >
> > > I'd like to remove old Python version - python{24,25,31,32,33}. I see no
> > > ports depend on python{31,32,33} and no one maintains them, but those
> > > ports are still kept for while. Is there a reason for not deleting them?
> >
> > Some of us like to test Python code against as many versions as possible.
> > It's bad enough to have to maintain locally patched versions of a few
> > Python-related ports just to expand the version lists, without having the
> > Python versions themselves disappear.
> >
>
> Hi,
>
> Thanks for pointing out a valid reason for keeping old Python versions. I know some projects still supporting as old as Python 3.2 or 2.6. Are there examples for Python 2.5 and 3.1?
>
> > My own philosophy is never to drop anything without a sound technical
> > reason, rather than just being "too old".  If the same zeal for
> > eliminating Python versions were applied to OS versions, MacPorts wouldn't
> > run on anything older than 10.12.
> >
>
> Well, upgrading from old Python versions is much easier than upgrading from old OS X versions. Due to Apple policies, new OS X versions do not work on old machines, and buying a new machine is apparently not an option for some people. In contrast, upgrading from Python 2.5 to 2.7 or 3.1 to 3.4+ takes almost no cost as CPython developers keep backward compatibility as best as they can do.
>
> Regarding "technical reasons" - there's one: old Python version does not build with OpenSSL 1.1, thus a blocker for upgrading the openssl port, and I don't think backporting fixes for openssl 1.1 is feasible as hundreds of lines should be patched.
>
> > Checking port dependents is inadequate, since it doesn't cover
> > "dependents" based on user interest.  If one were to remove all ports
> > without dependents, and iterate, there would be no ports at all. :-)
> >
>
> Of course I won't even consider ports with maintainers - there's at least one user :) I wrote this letter as those old Python versions are marked as nomaintainer (except python24, which the maintainer confirms he no longer needs it), so I wonder if there are still users for them.
>
> Regards,
>
> Chih-Hsuan Yen
>
> > Fred Wright

I removed Python 2.5 and Python 3.1 in
https://github.com/macports/macports-ports/commit/160f340665b9d97c1065fcb2aecb5b504a7b3cb4.
Python 3.2 and 3.3 are kept for now until most Python libraries drop
support for them. See https://hugovk.github.io/drop-python/ for
statistical data.

Cheers,

Chih-Hsuan Yen
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Remove old Python versions

Chih-Hsuan Yen
G Alexander <[hidden email]> 於 2018年10月27日 週六 下午5:09寫道:
>
> I run my system, stable, lean and mean.  You have to modify the python.tcl file and strip out all of the references in the portfiles.  I created a simple and fast bash script that replaces all of the python.version 2. blah blah to python.version 3.7  I did similar with php, perl.  see my bitbucket or github repo
>

Hi,

Could you describe more about your suggestions? I didn't find
python.tcl in MacPorts repos. And I can't find your repos. Could you
paste links?

And please use "reply all" so everyone on the mailing list can see your replies.

Cheers,

Chih

> > On Oct 27, 2018, at 04:38, Chih-Hsuan Yen <[hidden email]> wrote:
> >
> > Chih-Hsuan Yen <[hidden email]> 於 2018年10月24日 週三 上午11:12寫道:
> >>
> >>
> >> Fred Wright <[hidden email]> 於 2018年10月22日 週一 上午3:27寫道:
> >>>
> >>>
> >>> On Sun, 21 Oct 2018, Chih-Hsuan Yen wrote:
> >>>
> >>>> I'd like to remove old Python version - python{24,25,31,32,33}. I see no
> >>>> ports depend on python{31,32,33} and no one maintains them, but those
> >>>> ports are still kept for while. Is there a reason for not deleting them?
> >>>
> >>> Some of us like to test Python code against as many versions as possible.
> >>> It's bad enough to have to maintain locally patched versions of a few
> >>> Python-related ports just to expand the version lists, without having the
> >>> Python versions themselves disappear.
> >>>
> >>
> >> Hi,
> >>
> >> Thanks for pointing out a valid reason for keeping old Python versions. I know some projects still supporting as old as Python 3.2 or 2.6. Are there examples for Python 2.5 and 3.1?
> >>
> >>> My own philosophy is never to drop anything without a sound technical
> >>> reason, rather than just being "too old".  If the same zeal for
> >>> eliminating Python versions were applied to OS versions, MacPorts wouldn't
> >>> run on anything older than 10.12.
> >>>
> >>
> >> Well, upgrading from old Python versions is much easier than upgrading from old OS X versions. Due to Apple policies, new OS X versions do not work on old machines, and buying a new machine is apparently not an option for some people. In contrast, upgrading from Python 2.5 to 2.7 or 3.1 to 3.4+ takes almost no cost as CPython developers keep backward compatibility as best as they can do.
> >>
> >> Regarding "technical reasons" - there's one: old Python version does not build with OpenSSL 1.1, thus a blocker for upgrading the openssl port, and I don't think backporting fixes for openssl 1.1 is feasible as hundreds of lines should be patched.
> >>
> >>> Checking port dependents is inadequate, since it doesn't cover
> >>> "dependents" based on user interest.  If one were to remove all ports
> >>> without dependents, and iterate, there would be no ports at all. :-)
> >>>
> >>
> >> Of course I won't even consider ports with maintainers - there's at least one user :) I wrote this letter as those old Python versions are marked as nomaintainer (except python24, which the maintainer confirms he no longer needs it), so I wonder if there are still users for them.
> >>
> >> Regards,
> >>
> >> Chih-Hsuan Yen
> >>
> >>> Fred Wright
> >
> > I removed Python 2.5 and Python 3.1 in
> > https://github.com/macports/macports-ports/commit/160f340665b9d97c1065fcb2aecb5b504a7b3cb4.
> > Python 3.2 and 3.3 are kept for now until most Python libraries drop
> > support for them. See https://hugovk.github.io/drop-python/ for
> > statistical data.
> >
> > Cheers,
> >
> > Chih-Hsuan Yen
>