| View previous topic :: View next topic |
| Author |
Message |
Athenian200
n00b
Joined: 27 Nov 2005
Posts: 22
Location: Dallas, TX USA
|
 Posted: Mon Aug 03, 2020 10:57 pm Post subject: Is there an ebuild for Tauthon on Gentoo? |
 |
|
I happened to run across this bug and it makes me a little concerned:
https://bugs.gentoo.org/731114
I have a lot of stuff written for Python 2.x syntax that I can't easily migrate over to Python 3.x. I get that Python 2.x isn't maintained and is a security risk for that reason, but I'm curious if anyone would be interested in getting this project to build on Gentoo:
https://github.com/naftaliharris/tauthon
It's a fork of Python 2.7 that's still maintained, and incorporates a lot of features from 3.x that don't conflict with their goal of backwards compatibility with older Python 2.x projects. It seems like it would be really nice to have something like this to smooth the transition for anyone that's still has Python 2.x code that hasn't been modified yet.
Not expecting it to be officially supported or anything, but just tossing the idea out there in case anyone else is in the same boat. I couldn't find any threads discussing Tauthon before, I apologize if this was already posted. |
|
| Back to top |
|
 |
jburns
Veteran
Joined: 18 Jan 2007
Posts: 1214
Location: Massachusetts USA
|
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21725
|
| Posted: Tue Aug 04, 2020 1:53 am Post subject: |
|
|
| As I read that Gentoo bug, it is only about declaring that Portage may use Python 3.6 features without providing a fallback for when the user tries to use Python 2.x. It does not mean that Python 2.7 will be removed from the tree (although as I understand it, that may happen as a separate initiative). That bug only means that if you update Portage, you must have Python 3.6 or later to be guaranteed to be able to run the updated Portage. |
|
| Back to top |
|
|
Athenian200
n00b
Joined: 27 Nov 2005
Posts: 22
Location: Dallas, TX USA
|
| Posted: Tue Aug 04, 2020 4:19 am Post subject: |
|
|
Thanks, jburns! That's exactly what I was looking for.
| Hu wrote: | | As I read that Gentoo bug, it is only about declaring that Portage may use Python 3.6 features without providing a fallback for when the user tries to use Python 2.x. It does not mean that Python 2.7 will be removed from the tree (although as I understand it, that may happen as a separate initiative). That bug only means that if you update Portage, you must have Python 3.6 or later to be guaranteed to be able to run the updated Portage. |
Ah, thank you for clearing that up. I work on a project that has a lot of Python 2.x in it. We've been wanting to remove that dependency, but it's big and complex and we also try to keep compatibility with the latest GCC and glibc so the Python 2.x issue has been on the back burner.
Anyway, that bug started rumors that you guys had just dropped the ability to install Python 2.x, and so we started looking around for some kind of Python 2.x fork that was still maintained as well as an overlay for it, for developers that use Gentoo. I'm glad to hear that the ability to install 2.x hasn't been dropped yet. Hopefully those discussing dropping it from the tree are open to the possibility of using a maintained fork like Tauthon as a fallback for applications that simply haven't been updated to the new syntax and desperately need a stopgap. Otherwise, at least there's this overlay to fall back on. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21725
|
| Posted: Wed Aug 05, 2020 12:53 am Post subject: |
|
|
| I am not involved in the discussions about when Python 2.7 will be dropped from the tree. If I were to guess based on what I have observed, I would say that it will happen within a year, maybe much sooner. It is clear that many upstream projects are removing support for Python 2.7, and the Gentoo maintainers are updating packaged Python libraries accordingly. I am not sure if there are any cases where a Gentoo maintainer removed the Python 2.7 target from a package where upstream had not dropped support. Even if the maintainers are purely following the lead of the upstream projects, I think it is likely that keeping a large Python 2.7 project functional will rapidly become difficult due to its dependencies dropping support. You may wish to take the opportunity to transfer any packages you care about to an overlay while they are easy to transfer, so that you do not find in a few months that your program is broken due to its dependencies removing Python 2.7 support out from under you. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8938
|
| Posted: Wed Aug 05, 2020 6:15 am Post subject: |
|
|
The bug is indeed unrelated to global py2 support, it is only about the package manager code, which already requires py3 since sys-apps/portage-3.0.0.
| Hu wrote: | | I am not sure if there are any cases where a Gentoo maintainer removed the Python 2.7 target from a package where upstream had not dropped support. |
We drop python2_7 support regardless of upstream status, in order to relieve pressure on libraries that are already being released with minimum >=py3. Keeping it would be causing many skipped updates on those libraries, which many users regard as bugs even if they aren't, but eventually a skipped update will indeed turn into a blocker once a higher py3-only library version is required by one of its reverse dependencies. This has happened several times already and we want to avoid a proliferation of {matplotlib,numpy}-python2 etc. clones.
A fork of python2 really does not change anything about the above. |
|
| Back to top |
|
|
Athenian200
n00b
Joined: 27 Nov 2005
Posts: 22
Location: Dallas, TX USA
|
| Posted: Thu Aug 06, 2020 6:39 pm Post subject: |
|
|
Thanks for the above posts.
The situation with our project is somewhat unique. We're not depending on a whole lot of external libraries that are being gradually updated to Python 3. If we were, that would probably make the transition a lot easier and we probably would have started migrating to Python 3 already. Instead we have a whole bunch of custom internal libraries running on top of base Python 2.x cobbled together over the years that we would have to update to Python 3 ourselves if we wanted to go that route. We kind of had the false impression that Python 2 was a fairly stable scripting language that could be used for a long time, but now it's looking more like JavaScript or something where you're expected to go with the flow and use a lot of external libraries that will incorporate the latest features as the language evolves.
In our case, we really just need a Python 2.x/Tauthon engine that can interpret this huge interdependent mess of custom Python code we've written over the years with minimal changes, and thankfully none of it is facing a network. As bad as our situation is, the only thing we have to worry about is the Python 2.x interpreter itself going away forever and becoming impossible to compile with modern tools. Suffice it to say, for our purposes, we are kicking ourselves for listening to people who told us to go with Python 2.x because it was a stable API and wishing we'd chosen Perl 5.x for that purpose instead.
Anyway, hopefully the possibility of compiling either the Python 2.x interpreter or a fork of it remains an option on the table for people in our situation for a few more years to come. I appreciate the time and attention this thread has gotten from moderators and developers so far. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21725
|
| Posted: Fri Aug 07, 2020 1:54 am Post subject: |
|
|
| Athenian200 wrote: | | We kind of had the false impression that Python 2 was a fairly stable scripting language that could be used for a long time, but now it's looking more like JavaScript or something where you're expected to go with the flow and use a lot of external libraries that will incorporate the latest features as the language evolves. |
Python 2.6 was released roughly coincident to Python 3.0, and provided the first steps toward identifying code that would need to be changed. As I read the historical timeline, Python 2.6 was released in October 2008, and Python 3.0 followed in December 2008. Python 2.7 was released July 2010, and was originally scheduled to sunset in 2015. That was extended to 2020 to give people more time to update. I think the comparison to JavaScript is unfair. JavaScript requires the use of external libraries because the standard runtime historically was pathetically incomplete. JavaScript was years late providing relatively obvious features. For example, ECMAScript 2015 finally added let and const for local declarations, and proper maps (separate from the popular and unsafe hack of storing keys as properties on an object, and worrying about object attribute pollution). That standard was finalized months after Python 2.7 was originally scheduled to be fully abandoned. The timeline I checked didn't state when popular implementations finally supported the standard well enough that you could reliably use its features.
You don't say when you started using Python 2, but even if you started with it right when Python 2.7 was released, you were promised ~4.5 years and you ultimately got ~9.5 years. I think that qualifies as "a long time."
| Athenian200 wrote: | | As bad as our situation is, the only thing we have to worry about is the Python 2.x interpreter itself going away forever and becoming impossible to compile with modern tools. |
Given that Python is written in straight C, I rather doubt that modern tooling will lose the ability to build Python. At worst, you might need some patches to correct undefined behavior. You're probably in extensive company, as many projects have neglected to update, possibly with the belief that there would always be another Python 2.x deferral. | Athenian200 wrote: | | Suffice it to say, for our purposes, we are kicking ourselves for listening to people who told us to go with Python 2.x because it was a stable API and wishing we'd chosen Perl 5.x for that purpose instead. |
Python 2.x has been a stable API, as far as I know. Stay within Python 2.x (going from 2.5 -> 2.6 -> 2.7) and you will be fine. Your problem is that you assumed that every subsequent Python release would maintain full backward compatibility with 2.x, and that you don't have the testing resources to find where that does not hold true. For what it is worth, many projects found themselves with inadequate tests to support upgrading to Python 3. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Unsupported Software
