1 |
On Wed, 2007-10-10 at 19:47 +0200, René 'Necoro' Neumann wrote: |
2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
3 |
> Hash: SHA1 |
4 |
> |
5 |
> René 'Necoro' Neumann schrieb: |
6 |
> > Brian schrieb: |
7 |
> >> On Tue, 2007-09-10 at 23:54 +0200, René 'Necoro' Neumann wrote: |
8 |
> > |
9 |
> >>> This is the thing I'm waiting for atm ... the functions to implement (ie |
10 |
> >>> the API)... I think, that it should be done in a functional way is |
11 |
> >>> general consensus, isn't it? |
12 |
> >>> |
13 |
> >> Ok, I've put together a small list of portage calls mostly unigue, but |
14 |
> >> many have variations of the basic call (not listed)repeated for |
15 |
> >> different info returned. A few lines of code I left in to make it more |
16 |
> >> clear, but should give an overall list of the portage function calls |
17 |
> >> used so far. |
18 |
> > |
19 |
> > |
20 |
> >> I will put together a list of functions that I created in portagelib to |
21 |
> >> add functionality directly related to portage. Some of them are copies |
22 |
> >> of code chunks from lifted from gentoolkit. |
23 |
> > |
24 |
> >>> Regards, |
25 |
> >>> - - Necoro |
26 |
> > Thanks =) |
27 |
> > |
28 |
> > I've put it into the Wiki [1] too. :) |
29 |
> > |
30 |
> > I'll try again today to create some API documentation and will merge |
31 |
> > your requirements. |
32 |
> |
33 |
> Ok - I've added the current API to the wiki [1]. I did not manage to |
34 |
> include all of the needs of porthole, as I don't know what some of the |
35 |
> calls do, and whether they are really needed ;). |
36 |
> Please see the attached file for the comments. |
37 |
> |
38 |
> @dol-sen: Would be great if you could scan through the list and see, |
39 |
> which ones are really needed. Because portage calls inside functions |
40 |
> that are then moved into catapult don't need to have an equivalent in |
41 |
> the API (at least in most cases). - And for the vast majority I was just |
42 |
> clueless ^^. (and too lazy to lookup portage code). |
43 |
|
44 |
|
45 |
Yeah, I know... I made the list only for reference as to the calls to |
46 |
portage used. To know what they are used for, etc. you need to go thru |
47 |
portagelib. Many of the ones needed you already have blank defs for and |
48 |
raise NotImplemented ERROR. I didn't expect you to implement them all |
49 |
now anyway :) |
50 |
|
51 |
|
52 |
> |
53 |
> There are certain issues with the current API: |
54 |
> |
55 |
> 1.) Add some more stuff needed by other frontends. |
56 |
> 2.) Perhaps merge the Package and the System object as they both just |
57 |
> provide functions. |
58 |
|
59 |
I had a chance to look over your code a little more. I think it would |
60 |
be less confusing if some of the files and classes were renamed. You've |
61 |
used package.py and class XXXPackage several times. It gets confusing |
62 |
with a frontend's Package class... Since they are just function groups |
63 |
then perhaps |
64 |
|
65 |
class CPVFunctions |
66 |
|
67 |
Anyway, I have some ideas on how we might organize groups of functions, |
68 |
but I need more time to think it thru and get them down in print. |
69 |
|
70 |
> 3.) Merge package.is_in_overlay() and package.get_overlay_path() |
71 |
> 4.) Get rid of the different get_*_settings functions and add special |
72 |
> ones: get_homepage, get_depend(which), get_arch, ... |
73 |
> 5.) Currently there are two functions returning use flags which were set |
74 |
> at installation time of a package: |
75 |
> - get_use_flags(): Returning ALL set useflags |
76 |
> - get_installed_use_flags(): Return only the set useflags which are |
77 |
> also in IUSE. |
78 |
> This should perhaps be merged into one function with an attribute |
79 |
> "only_iuse" or similar. |
80 |
> |
81 |
> Some comments are appreciated ;) |
82 |
> |
83 |
> - - Necoro |
84 |
|
85 |
Sorry, I have to work again tonight. I won't have time to look yet. |
86 |
Only enough time to respond with this email. |
87 |
|
88 |
-- |
89 |
Brian <dol-sen@×××××.net> |
90 |
|
91 |
-- |
92 |
gentoo-guis@g.o mailing list |