Re: [gentoo-guis] One backend for all portage GUIs

[Brian]

On Wed, 2007-10-10 at 19:47 +0200, René 'Necoro' Neumann wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> René 'Necoro' Neumann schrieb:
> > Brian schrieb:
> >> On Tue, 2007-09-10 at 23:54 +0200, René 'Necoro' Neumann wrote:
> >
> >>> This is the thing I'm waiting for atm ... the functions to implement (ie
> >>> the API)... I think, that it should be done in a functional way is
> >>> general consensus, isn't it?
> >>>
> >> Ok, I've put together a small list of portage calls mostly unigue, but
> >> many have variations of the basic call (not listed)repeated for
> >> different info returned. A few lines of code I left in to make it more
> >> clear, but should give an overall list of the portage function calls
> >> used so far.
> >
> >
> >> I will put together a list of functions that I created in portagelib to
> >> add functionality directly related to portage.  Some of them are copies
> >> of code chunks from lifted from gentoolkit.
> >
> >>> Regards,
> >>> - - Necoro
> > Thanks =)
> >
> > I've put it into the Wiki [1] too. :)
> >
> > I'll try again today to create some API documentation and will merge
> > your requirements.
>
> Ok - I've added the current API to the wiki [1]. I did not manage to
> include all of the needs of porthole, as I don't know what some of the
> calls do, and whether they are really needed ;).
> Please see the attached file for the comments.
>
> @dol-sen: Would be great if you could scan through the list and see,
> which ones are really needed. Because portage calls inside functions
> that are then moved into catapult don't need to have an equivalent in
> the API (at least in most cases). - And for the vast majority I was just
> clueless ^^. (and too lazy to lookup portage code).


Yeah, I know...  I made the list only for reference as to the calls to
portage used.  To know what they are used for, etc. you need to go thru
portagelib.  Many of the ones needed you already have blank defs for and
raise NotImplemented ERROR.  I didn't expect you to implement them all
now anyway :)


>
> There are certain issues with the current API:
>
> 1.) Add some more stuff needed by other frontends.
> 2.) Perhaps merge the Package and the System object as they both just
> provide functions.

I had a chance to look over your code a little more.  I think it would
be less confusing if some of the files and classes were renamed.  You've
used package.py and class XXXPackage several times.  It gets confusing
with a frontend's Package class...   Since they are just function groups
then perhaps 

class CPVFunctions

Anyway, I have some ideas on how we might organize groups of functions,
but I need more time to think it thru and get them down in print. 

> 3.) Merge package.is_in_overlay() and package.get_overlay_path()
> 4.) Get rid of the different get_*_settings functions and add special
> ones: get_homepage, get_depend(which), get_arch, ...
> 5.) Currently there are two functions returning use flags which were set
> at installation time of a package:
> 	- get_use_flags(): Returning ALL set useflags
> 	- get_installed_use_flags(): Return only the set useflags which are
> also in IUSE.
> This should perhaps be merged into one function with an attribute
> "only_iuse" or similar.
>
> Some comments are appreciated ;)
>
> - - Necoro

Sorry, I have to work again tonight.  I won't have time to look yet.
Only enough time to respond with this email.

-- 
Brian <dol-sen@×××××.net>

-- 
gentoo-guis@g.o mailing list