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