1 |
Mike Frysinger wrote: |
2 |
> Alexey Shvetsov wrote: |
3 |
>> Mike Frysinger писал: |
4 |
>> > Ryan Hill wrote: |
5 |
>> >> Is there any sane way to handle sub-eclasses? eg. foo-base inherits |
6 |
>> >> foo-functions. |
7 |
>> > |
8 |
>> > i was thinking of extending the metadata to handle this. did you |
9 |
>> > have any |
10 |
>> > specific ideas in mind ? i can see inheriting say distutils should |
11 |
>> > not require |
12 |
>> > people to also inherit python eclasses ... |
13 |
>> |
14 |
>> May we can use eclass dep graph? |
15 |
> |
16 |
> no ... that sort of defeats the whole reason that drove this work. we |
17 |
> don't want the mere fact that one eclass inherits another to imply that |
18 |
> it's part of |
19 |
> that eclasses guaranteed API. a lot of eclasses inherit eutils, but i |
20 |
> don't think any of them should be guaranteeing that inherit which means |
21 |
> ebuilds need to include it themselves if they use functions from it (like |
22 |
> epatch). |
23 |
> |
24 |
> there are a cases with split up or hierarchical eclasses (java, mysql, qt, |
25 |
> php, python, xorg come to mind) where the entry point might vary, but they |
26 |
> all share core eclasses that largely should not be inherited by the end |
27 |
> ebuild. |
28 |
> |
29 |
> maybe a new eclass-level keyword @INHERITED-API ? it takes a space |
30 |
> delimited |
31 |
> list of eclasses that are guaranteed by the API. so in distutils.eclass, |
32 |
> we'd add: |
33 |
> # @INHERITED-API: python |
34 |
> |
35 |
> and repoman would use this to build a tree of implicit funcs to allow |
36 |
> w/out a direct inherit. |
37 |
|
38 |
++ That sounds like a clean solution to me. |
39 |
|
40 |
> Steven J Long wrote: |
41 |
>> You could maybe tighten the false-negative side by scanning all functions |
42 |
>> defined in an eclass, and warning if they're undocumented. |
43 |
> |
44 |
> that happens now when you emerge eclass-manpages, but i suspect no one |
45 |
> cares. if you run the script by hand on your eclass, it'll tell you the |
46 |
> same thing. |
47 |
|
48 |
So, if eclass-manpages /is/ installed, then it gets used to check the |
49 |
documentation by repoman? |
50 |
|
51 |
Why not just make it a required dependency, so it's "a new feature"? It may |
52 |
well be that people just don't know about it, and would welcome repoman a |
53 |
reminder to update eclass documentation (eg hard error if they added the |
54 |
function, overrideable error if they've edited the eclass, and warning if |
55 |
they are just using it, latter two of which could perhaps talk to pybugz.) |
56 |
|
57 |
After all, it's their name on the commit. |
58 |
|
59 |
Regards, |
60 |
Steve. |
61 |
-- |
62 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |