1 |
On 18-06-2010 01:27:57 -0700, Brian Dolbec wrote: |
2 |
> Unless I'm way off the mark, your suggesting to re-code portage into "C" |
3 |
> then create a python interface to it. Others have started such a |
4 |
> project, but none have completed aside from paludis (C++). |
5 |
|
6 |
It's actually on my wishlist for a long time, just because Python is an |
7 |
extreme pain in my environments, and given its current maintainer it is |
8 |
going to be an extreme pain for a long time as well. |
9 |
|
10 |
> If there are other apps that would like to get info from portage via |
11 |
> this API, that is fine with me. I have intentions of making the "C" |
12 |
> interface available to all apps that desire to. If there is data that |
13 |
> they want to get from portage via the API, then they should send their |
14 |
> wish list in and we'll do our best to get it in there for them. |
15 |
> |
16 |
> Currently the API will be based on the packagekit portage backend code |
17 |
> that was produced last summer and other code from porthole, portato, |
18 |
> kportagetray. We are also going to put together a layman API for |
19 |
> consumer apps (guis frontends) to use to operate layman without the need |
20 |
> to run it in and parse terminal output. It too will hopefully be |
21 |
> available via a "C" interface for non-python apps. |
22 |
|
23 |
I don't want to push you into the C corner, but tools like qfile and |
24 |
qlist are in orders of magnitude faster than their equery variants for a |
25 |
good reason. Maybe this simple command gives you an idea why I think |
26 |
python and portage are slow. |
27 |
|
28 |
% time portageq envvar CHOST |
29 |
powerpc-apple-darwin8 |
30 |
0.488u 0.704s 0:03.09 38.1% 0+0k 25+70io 0pf+0w |
31 |
|
32 |
(three full seconds to return a very simple var) |
33 |
|
34 |
That said, if you design C APIs, please design them from a C point of |
35 |
view, initially implemented by your Python functionality doing the |
36 |
necessary wrapping to get a sane C structure. Then they can be replaced |
37 |
by native C code as RSI and time permits in the future. |
38 |
|
39 |
|
40 |
-- |
41 |
Fabian Groffen |
42 |
Gentoo on a different level |