Gentoo Archives: gentoo-python

From: Ben de Groot <yngwin@g.o>
To: "Michał Górny" <mgorny@g.o>
Cc: gentoo-python@l.g.o
Subject: Re: [gentoo-python] To refactor python-distutils-ng or introduce distutils-r1?
Date: Sun, 30 Sep 2012 05:16:15
Message-Id: CAB9SyzSytFqy7j7f3mr4nZvYebPsWZmQfrQXHL-EJCqMAzvZAA@mail.gmail.com
In Reply to: [gentoo-python] To refactor python-distutils-ng or introduce distutils-r1? by "Michał Górny"
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

Replies