Re: [gentoo-portage-dev] [API] First steps for creating an API for portage

[Brian Dolbec]

On Fri, 2010-06-18 at 08:35 +0200, Fabian Groffen wrote:
> On 18-06-2010 02:08:04 +0200, René 'Necoro' Neumann wrote:
> > In parallel (or thereafter), we build the C-bindings. The API for these
> > bindings probably look different -- but I guess they should be
> > implemented in terms of the library created above.
> >
> > By example:
> >
> > - Operation: get the list of categories
> > - Python-API: portage.api.categories() : Category list
> > - Implementation: def categories(): return ....
> > - C-API: category * categories()
> > - C-Implementation: some wrapper around portage.api.categories
>
> If you want to deliver a C implementation, I'd wonder why you wouldn't
> just make a full C implementation and create Python wrappers for them
> instead of the other way around.  Might accidentially speed up Portage,
> and make tools like portage-utils happy.
>
>

Unless I'm way off the mark, your suggesting to re-code portage into "C"
then create a python interface to it.  Others have started such a
project, but none have completed aside from paludis (C++).

What we are trying to do is make a higher level interface API that will
do several low level portage operations/calls to produce data for API
consumers like the gui frontends to portage.  To do that in "C" would
require several data conversions from python data types to CTYPES and
back.  Then convert the final results back to python for python consumer
APPS.  I do not see how that would speed up portage as emerge and normal
portage operations will not have anything to do with this API aside from
the consumer apps calls to this api that will in turn run some emerge
operations or do data gathering via portage function calls.

Currently there are 3 gui's that are python based (porthole, portato and
kportagetray), 3 that are in other languages (Himerge in Haskel, Kuroo
in C++, packagekit in C).  These last 3 can make use of a "C" interface
to this new API instead of trying to decode the metadata cache directly,
etc..

If there are other apps that would like to get info from portage via
this API, that is fine with me.  I have intentions of making the "C"
interface available to all apps that desire to.  If there is data that
they want to get from portage via the API, then they should send their
wish list in and we'll do our best to get it in there for them.

Currently the API will be based on the packagekit portage backend code
that was produced last summer and other code from porthole, portato,
kportagetray.  We are also going to put together a layman API for
consumer apps (guis frontends) to use to operate layman without the need
to run it in and parse terminal output.  It too will hopefully be
available via a "C" interface for non-python apps.
-- 
Brian Dolbec <brian.dolbec@×××××.com>