On Sun, Sep 20, 2009 at 06:20:41PM -0400, Mark Loeser wrote: > Arfrever Frehtes Taifersar Arahesis <arfre...@gentoo.org> said: > > I agree. But Python 3.1 doesn't have more issues than Python 2.6, so > > the stabilization is reasonable. > > And how about all of the packages in the tree that use python? You are > missing that huge part. That's like saying libfoo works absolutely > great, but every single application that links to libfoo now breaks with > the new release of libfoo-2.0. The things that use your package are > just as important when looking to stablize something or to move it out > of package.mask.
Mark pretty much nailed it on the head. Before even looking at stabilizing py3k it probably would be a good idea to identify what libs/frameworks actually *work* with it out of the box. Keep in mind that gentoo pkging of python ebuilds isn't slotted on python version- meaning you wind up with either setuptools for 2.5 or for 2.6. Then you take a look at the larger frameworks like numpy and twisted to see if they actually support 3k w/ existing releases. Not a huge number do, at least for actual releases (random branches don't count here). If the big boys don't support 3k yet, it doesn't much matter if the small fry do, thus the gain from having py3k stabilized is way less and the cost in terms of user annoyance is way larger. Regardless of the potential portage issue, I honestly don't think the state of python libs is at the point that running purely py3k w/ single slotting of python pkgs is viable. Basically what gain is there? Stabilizing it at this point comes off as "whee, we have py3k stabilized! Now go mask it on all of your boxes since not a lot of the useful things play nice with it right now!" My 2 cents. ~harring
pgpaf2ifqTp0S.pgp
Description: PGP signature
