| 1 |
On 9 September 2012 06:00, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> I've just looked through python-distutils-ng again and I think it |
| 3 |
> deserves at least a bit of changes, if not complete redesign. |
| 4 |
|
| 5 |
Sounds to me like you want to write a new eclass, not a few changes to |
| 6 |
the existing one. Major changes to an eclass are a recipe for disaster |
| 7 |
(just consider the messy history of the python and distutils |
| 8 |
eclasses). |
| 9 |
|
| 10 |
> It is currently used by 22 packages in Gentoo, and probably a few |
| 11 |
> in the overlays. I'd honestly prefer to avoid further packages doing |
| 12 |
> that before we decide on how to proceed. That's why the first patch I'm |
| 13 |
> suggesting somehow marks is as work-in-progress and asks people not to |
| 14 |
> use it yet. |
| 15 |
|
| 16 |
Please don't. As it is, the python-distutils-ng is much more usable |
| 17 |
than the overcomplicated python and distutils eclasses. I recommend |
| 18 |
everyone to use it for new ebuilds. |
| 19 |
|
| 20 |
> The second and third patches just fix one of the formal problems. |
| 21 |
> |
| 22 |
> The fourth patch completely removes PYTHON_OPTIONAL support. It is not |
| 23 |
> used by any of the mentioned packages right now and that way I'd like to |
| 24 |
> avoid it being used by anything else, before we redesign it. |
| 25 |
|
| 26 |
Sounds good. |
| 27 |
|
| 28 |
> The major issue I see with it is that it hardcodes the 'python' flag. |
| 29 |
> That's a bit mistaken, I believe. Not that I see much use for |
| 30 |
> an optional Python support in package using distutils, and if there is |
| 31 |
> one, I believe developers will find it more comfortable to do: |
| 32 |
> |
| 33 |
> use python && python-distutils-ng_src_compile |
| 34 |
> |
| 35 |
> than expect the eclass to do that check for them. |
| 36 |
|
| 37 |
I agree here. |
| 38 |
|
| 39 |
> We also should think about USE-dependencies more (I will think about it |
| 40 |
> myself, trying to find some working solution better than one suggested |
| 41 |
> by Arfrever [the <<[use]>>]). It will be hard thinking... |
| 42 |
> |
| 43 |
> And one thing certainly needing discussing is extracting some |
| 44 |
> common-python code to a separate eclass, without the distutils part. |
| 45 |
> To be honest, I'd rather move the whole 'optionality' of Python there. |
| 46 |
|
| 47 |
Sounds good. |
| 48 |
|
| 49 |
> And lastly, the name. Considering the amount of work that needs to be |
| 50 |
> done, we might also decide to 'lastrite' the eclass and work on a new |
| 51 |
> one, replacing 'ng' with something saner. |
| 52 |
|
| 53 |
Yes, once your new eclass(es) is/are in place, we can migrate existing |
| 54 |
ebuilds and lastrite the current eclass(es). Unfortunately, we don't |
| 55 |
have a method for versioning eclasses in place, so we have to do it |
| 56 |
the clunky way of introducing new eclasses with new names. |
| 57 |
|
| 58 |
-- |
| 59 |
Cheers, |
| 60 |
|
| 61 |
Ben | yngwin |
| 62 |
Gentoo developer |
| 63 |
Gentoo Qt project lead, Gentoo Wiki admin |
Archives