1 |
On 26 September 2012 21:16, Michał Górny <mgorny@g.o> wrote: |
2 |
> Hello, |
3 |
> |
4 |
> I'd like to bring a quick topic, preferably answered yes/no, preferably |
5 |
> after reading the remaining part ;). |
6 |
> |
7 |
> Considering that python-r1 patches so far are clean, should I: |
8 |
> |
9 |
> a) integrate python-distutils-ng with python-r1 and change its API |
10 |
> as listed below (the API changes don't collide with any used |
11 |
> functionality), |
12 |
> |
13 |
> b) leave python-distutils-ng in place and work on distutils-r1 with |
14 |
> a clean start. |
15 |
> |
16 |
> |
17 |
> And now what changes in API will be necessary to make p-d-ng play nice |
18 |
> with python-r1. I've assumed that functions prefixed with an underscore |
19 |
> are private and didn't care about them. |
20 |
> |
21 |
> None of the listed features are used by any ebuild in the tree, unless |
22 |
> I have missed something ;). |
23 |
> |
24 |
> 1. Remove PYTHON_OPTIONAL -- I really dislike the way it is done |
25 |
> (it's practically a switch to hardwire 'python?' in a few places, |
26 |
> without any flexibility); |
27 |
> |
28 |
> 2. Convert PYTHON_COMPAT to an array -- this will usually mean that |
29 |
> ebuilds can't look up ${PYTHON_COMPAT} safely (the change is done |
30 |
> for practical reasons); |
31 |
> |
32 |
> 3. Stop passing Python ABI and executable as parameters to phase |
33 |
> functions -- these are not really useful (since they are available |
34 |
> as ${EPYTHON} and ${PYTHON} anyway. Removing them will allow me to |
35 |
> implement a 'foreach' function being able to pass arbitrary |
36 |
> parameters to invoked commands. |
37 |
> |
38 |
> What do you think? Should I change p-d-ng ABI like that (errr, how I |
39 |
> hate that name) or just introduce a new eclass? |
40 |
> |
41 |
> -- |
42 |
> Best regards, |
43 |
> Michał Górny |
44 |
|
45 |
Sorry for the (relatively) late reply. I was very busy this week. |
46 |
|
47 |
IIRC I mentioned before that I prefer new eclasses over changing the |
48 |
existing ones (in absence of a real eclass versioning system). |
49 |
Actually a good point was raised on -dev ML about using multiple |
50 |
smaller eclasses, instead of one over-complicated one that tries to do |
51 |
too much. |
52 |
|
53 |
I 100% support going for python-r1 and distutils-r1, deprecating the |
54 |
existing eclasses in use now. We may need to add one or two more new |
55 |
eclasses, to replace functionality from current python.eclass. |
56 |
|
57 |
-- |
58 |
Cheers, |
59 |
|
60 |
Ben | yngwin |
61 |
Gentoo developer |
62 |
Gentoo Qt project lead, Gentoo Wiki admin |