Created attachment 219523 [details]
Patch file for new port
Small description (see pkg-desc in diff):
Tauthon is a backward-compatible fork of Python's 2.7.18 interpreter with new syntax, builtins, and libraries backported from Python 3.x.
Python code and C-extensions targeting Python 2.7 or below are expected to run unmodified on Tauthon and produce the same output. But with Tauthon, that code can now use some of the new features from Python 3.x.
Tauthon can be used with old code bases that will take time to migrate (or won't be migrated at all). My use case is the build infrastructure for New Moon, which I'll submit next as a new port.
This port is modeled after lang/python27, with irrelevant bits (AFAIK) removed, and specific ones added. As lang/python*, core modules with big dependencies are omitted, and should be re-enabled in other ports (I did not do it since I don't have any immediate use for them).
No changes were made to Uses/python.mk, so currently no existing py-* port can use this version automatically. bapt@ is against such a change, but it might be useful for folks that want to install some packages under Tauthon (I currently don't have any use for this), although I guess that 'pip' could be used instead.
I intend to maintain it, but I'd be happy to defer to python@ (and participate there from time to time) if you prefer.
(In reply to Olivier Certner from comment #0)
A great contribution, Olivier. Thank you!
I hope it is imported into the ports tree quickly. :-)
Not sure if this is a good idea since Python 2.7 is going to get axed soon as it's EOL upstream. Looking at commit rate this is seems likely to face the same fate (abandonware).
(In reply to daniel.engberg.lists from comment #2)
The commit rate for a project like Tauthon, whose aim is to continue maintaining Python 2.7 (bugs, security, and the occasional backport of 3.x features), which itself has been in maintenance mode in the past years, is hardly a relevant metric. Clearly, it will remain low compared to ones in expansion. And it actually *should*, without a change in the project goal.
If you dig on GitHub a bit more, you'll see that there was a change in maintainership about 2 years ago, which went smoothly, and several guys very much interested in making sure it continues (e.g., one runs his startup infrastructure on it).
I'm pretty sure there are lots of ports in the tree for projects who haven't seen many commits in *years*. This is hardly a problem as long as they still build and are used/maintained by some.
It may save those ports that upstream maintainers have put on life support (i. e. only security/critical fixes) but where the upstream maintenance moved elsewhere.
Marking it a blocker on #249337.