Gentoo Archives: gentoo-portage-dev

From: Brian Dolbec <brian.dolbec@×××××.com>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] [API] First steps for creating an API for portage
Date: Fri, 18 Jun 2010 09:03:25
In Reply to: Re: [gentoo-portage-dev] [API] First steps for creating an API for portage by Fabian Groffen
1 On Fri, 2010-06-18 at 08:35 +0200, Fabian Groffen wrote:
2 > On 18-06-2010 02:08:04 +0200, René 'Necoro' Neumann wrote:
3 > > In parallel (or thereafter), we build the C-bindings. The API for these
4 > > bindings probably look different -- but I guess they should be
5 > > implemented in terms of the library created above.
6 > >
7 > > By example:
8 > >
9 > > - Operation: get the list of categories
10 > > - Python-API: portage.api.categories() : Category list
11 > > - Implementation: def categories(): return ....
12 > > - C-API: category * categories()
13 > > - C-Implementation: some wrapper around portage.api.categories
14 >
15 > If you want to deliver a C implementation, I'd wonder why you wouldn't
16 > just make a full C implementation and create Python wrappers for them
17 > instead of the other way around. Might accidentially speed up Portage,
18 > and make tools like portage-utils happy.
19 >
20 >
22 Unless I'm way off the mark, your suggesting to re-code portage into "C"
23 then create a python interface to it. Others have started such a
24 project, but none have completed aside from paludis (C++).
26 What we are trying to do is make a higher level interface API that will
27 do several low level portage operations/calls to produce data for API
28 consumers like the gui frontends to portage. To do that in "C" would
29 require several data conversions from python data types to CTYPES and
30 back. Then convert the final results back to python for python consumer
31 APPS. I do not see how that would speed up portage as emerge and normal
32 portage operations will not have anything to do with this API aside from
33 the consumer apps calls to this api that will in turn run some emerge
34 operations or do data gathering via portage function calls.
36 Currently there are 3 gui's that are python based (porthole, portato and
37 kportagetray), 3 that are in other languages (Himerge in Haskel, Kuroo
38 in C++, packagekit in C). These last 3 can make use of a "C" interface
39 to this new API instead of trying to decode the metadata cache directly,
40 etc..
42 If there are other apps that would like to get info from portage via
43 this API, that is fine with me. I have intentions of making the "C"
44 interface available to all apps that desire to. If there is data that
45 they want to get from portage via the API, then they should send their
46 wish list in and we'll do our best to get it in there for them.
48 Currently the API will be based on the packagekit portage backend code
49 that was produced last summer and other code from porthole, portato,
50 kportagetray. We are also going to put together a layman API for
51 consumer apps (guis frontends) to use to operate layman without the need
52 to run it in and parse terminal output. It too will hopefully be
53 available via a "C" interface for non-python apps.
54 --
55 Brian Dolbec <brian.dolbec@×××××.com>


File name MIME type
signature.asc application/pgp-signature