1 |
Hi, |
2 |
|
3 |
On Sat, May 26, 2012 at 11:32 AM, Maxim Koltsov <maksbotan@g.o> wrote: |
4 |
> First of all, how well is this eclass adapted to packages not using |
5 |
> distutils? Old eclass had set of convenient functions |
6 |
> (python_execute_function, python_generate_wrapper_scripts, |
7 |
> python_conver_shebangs). I see some functions like these ones in new |
8 |
> eclass, but can they serve as good replace and is their API public and |
9 |
> stable? |
10 |
|
11 |
We will have to make sure there is good support for non-distutils |
12 |
packages, it will just take some time and good bug reports about what |
13 |
you need from the eclass. If you're asking if these new functions are |
14 |
a good replacement, are public and stable, it seems you haven't yet |
15 |
decided they're not. I don't think we (as in the python team) are |
16 |
promoting python-distutils-ng as the default eclass *at this time*, so |
17 |
it might take some time to work things out, but hopefully we can find |
18 |
good solutions to all the issues you mention here. |
19 |
|
20 |
> Then, we think that this ruby-ng style approach with PYTHON_TARGETS is |
21 |
> a bit uncomfortable for end users and developers. This is going to be |
22 |
> pain for all users if eclass gets used widely. Eclass allows developer |
23 |
> not to set PYTHON_COMPAT and populate it with all available values — |
24 |
> well, it's nice. But imagine that Python 3.3 arrives. All ebuilds |
25 |
> using new eclass will get new IUSE and therefore will be rebuilt |
26 |
> during emerge --update --newuse world. That's hardly sensible. It's |
27 |
> awful to rebuild packages which might be very 'heavy' just for |
28 |
> nothing. |
29 |
> On the other hand, if developers are forced to set PYTHON_COMPAT, this |
30 |
> will result in great delays in getting new python support to Gentoo. |
31 |
> You can say that ruby-ng has the same behavior and nobody complains. |
32 |
> But python is not ruby. Ruby 1.8 to 1.9 transitition was connected |
33 |
> with a lot of incompabilities, so one could not assume that ruby-1.8 |
34 |
> package will work on 1.9. Python 3.2 to 3.3 transitition should be |
35 |
> harmless and almost all packages will require no changes. So some |
36 |
> implicit mechanism of doing this must be implemented. |
37 |
|
38 |
So I think the second part of this (x.y to x.y+1 transitions, in the |
39 |
Python world, are generally relatively smooth) invalidates your point |
40 |
in the first part: if the transitions are generally smooth, then yes, |
41 |
when Python 3.3 gets stabilized, I want all of my Python packages to |
42 |
be available from the 3.3 interpreter. I agree that it's annoying to |
43 |
have to rebuild all those packages, but on the other hand, rebuilding |
44 |
the Python parts of my system every 18 months or so doesn't seem that |
45 |
big of an issue compared to the upside. And the parts that you least |
46 |
want to rebuild (e.g. big binary Python modules) are probably the ones |
47 |
that it would be hardest to think of some alternate solution for, so |
48 |
let's not even go there. |
49 |
|
50 |
> So, new eclass has serious problems, old is bad too, not to say here |
51 |
> why, and we have no solution yet :) |
52 |
> But still discussion is needed, or we will end up accepting silently |
53 |
> bad decisions. Please speak up everyone who agrees with me and/or has |
54 |
> any suggestions. |
55 |
|
56 |
> I want to say that I personally don't want to use python-distutils-ng |
57 |
> in its current state and I know several active python ebuild writers |
58 |
> that are not Gentoo developers and they don't want to use it too. |
59 |
|
60 |
Given all of the above, these two paragraphs seem a little bit vague |
61 |
and alarmist to me. Yes, the new eclass isn't perfect. We don't expect |
62 |
it to be, certainly not given the short time it's been in the tree. |
63 |
But I don't think your implicit suggestion that the python team or |
64 |
anyone involved is "silently accepting bad decisions" is warranted. |
65 |
Obviously no one should be shy about raising actual issues he/she has |
66 |
with the ebuild or suggesting improvements (and as far as I've seen, |
67 |
people haven't been, but maybe I'm not talking to the same people you |
68 |
are). |
69 |
|
70 |
So, I'd prefer it if, instead of speaking up about general concerns |
71 |
that the new eclass isn't ready or has serious problems, people please |
72 |
file one bug each about each serious problem they have run into, |
73 |
found, or are concerned about, CC the python team, and we'll try to |
74 |
take a look. |
75 |
|
76 |
Cheers, |
77 |
|
78 |
Dirkjan |