| |||||||||||||
|
| |||||||||||||
Python 3.0 releasedPython 3.0 releasedPosted Dec 5, 2008 22:16 UTC (Fri) by nevyn (subscriber, #33129)In reply to: Python 3.0 released by iabervon Parent article: Python 3.0 released
It's true that Fedora hasn't had much pressure to move to a new version of Python when it didn't want to before. However there are multiple precedents now of Fedora dropping packages after a move to a new version (because they depended on an older version). The biggest victim being Zope.
So I find it very believable that Fedora will just keep saying "either your package works with 2.* or we don't ship it" for anything which comes along that "requires py3k". More likely is that upstreams will use 2.* as the baseline for a significant amount of time to come, much like people didn't all move to Apache-httpd-2.* instantly.
(Log in to post comments)
Python 3.0 released Posted Dec 5, 2008 22:27 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
however there is defiantly going to be some project that is going to move to python 3.0 immediately.
you are assuming that one of the goals of the project is to be included into Fedora so Fedora can lay down requirements (like "don't use Python 3")
other systems will use Python 3 and programmers will write things in Python 3.
if Fedora wants to include these things they will need to include Python 3 or re-write them
there is another thread this week in the LWN comments where people are advocating that the distros should not modify any packages and should just ship the upstream packages unmodified. this is an example of how it's not going to be possible.
Python 3.0 released Posted Dec 5, 2008 23:28 UTC (Fri) by jspaleta (subscriber, #50639) [Link]
The real problem is what this means for upstream developers. If the language incompatibilities are mostly cosmetic then downstream distributors will be able to hold a transitional patchset together without the upstream developers having to branch, upstream can just make the move to py3k and the cosmetic changes can be generated to make a py2.x variant. But for codebases which have to make deep changes, or make heavy use of additional python based projects, they will most likely have to branch and coordinate porting into py3k with the other python module projects.
Either way its going to be painful..and messy.
-jef
Python 3.0 released Posted Dec 6, 2008 0:23 UTC (Sat) by iabervon (subscriber, #722) [Link]
In a lot of situations, it's trivial to have some software use python2 and other software use python3. An apache transition is a lot more difficult, because you can't really have half your site served with one apache and the other half served with a different version (on one IP and all on port 80 without a ton of annoying redirection).
Python 3.0 released Posted Dec 8, 2008 18:16 UTC (Mon) by nevyn (subscriber, #33129) [Link]
Actually "in a lot of situations" it's trivial to run two different Apache-httpd's ... the problem is all the other situations where it's a giant PITA.
The same is true of python, yes it's possible to run two versions in some situations ... but due to all the other situations Fedora has said "there will be only one". AIUI Debian ship multiple versions of python, but only one version of some (all?) modules ... which doesn't seem that useful. It'll be interesting to see how Debian manage the py3k transition.
Python 3.0 released Posted Dec 14, 2008 6:08 UTC (Sun) by njs (subscriber, #40338) [Link]
In Debian, in almost all cases, there is a single package for each library, but at install-time that package detects which versions of python are installed and automatically sets up the library to work with all of them (including running multiple byte-compiles, etc.). This system is called "python-support".
|
|
||||||||||||