1 |
> So I think the second part of this (x.y to x.y+1 transitions, in the |
2 |
> Python world, are generally relatively smooth) invalidates your point |
3 |
> in the first part: if the transitions are generally smooth, then yes, |
4 |
> when Python 3.3 gets stabilized, I want all of my Python packages to |
5 |
> be available from the 3.3 interpreter. |
6 |
Let's take a "stable" user who updates (`emerge --update --deep --newuse |
7 |
@world`) his/her system regularly. |
8 |
Python 3.3 is released, added to Portage tree and eventually unmasked. |
9 |
PYTHON_TARGETS variable is changed to include 3.3. And suddenly `emerge |
10 |
--newuse @world` on stable system suggests rebuilding of every package |
11 |
using new eclass, because new (though disabled) USE-flags was added. And |
12 |
when Python 3.3 is keyworded stable, hence bringing new default |
13 |
PYTHON_TARGETS, user should now rebuild those packages once more, but now, |
14 |
at least, not uselessly. |
15 |
|
16 |
Just yesterday I had www-servers/uwsgi recompiled because of changed |
17 |
RUBY_TARGETS. And I even have no Ruby installed. |
18 |
|
19 |
> So, I'd prefer it if, instead of speaking up about general concerns |
20 |
> that the new eclass isn't ready or has serious problems, people please |
21 |
> file one bug each about each serious problem they have run into, |
22 |
> found, or are concerned about, CC the python team, and we'll try to |
23 |
> take a look. |
24 |
I had written about problems with new eclass a couple of weeks ago here. |
25 |
Not that anybody cares that now any user not caring about dev-lang/python |
26 |
explicitly would get Python 2.7 and all his modules compiled twice for no |
27 |
good reason (except "we can't think out more sensible default for new |
28 |
eclass"). Whether or not does he *really* need Python 2.x or stable and |
29 |
included-in-stage3 Python 3.2 suffices for him. |