On 18-06-2010 01:27:57 -0700, Brian Dolbec wrote:
> 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++).

It's actually on my wishlist for a long time, just because Python is an
extreme pain in my environments, and given its current maintainer it is
going to be an extreme pain for a long time as well.

> 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.

I don't want to push you into the C corner, but tools like qfile and
qlist are in orders of magnitude faster than their equery variants for a
good reason.  Maybe this simple command gives you an idea why I think
python and portage are slow.

% time portageq envvar CHOST
powerpc-apple-darwin8
0.488u 0.704s 0:03.09 38.1%     0+0k 25+70io 0pf+0w

(three full seconds to return a very simple var)

That said, if you design C APIs, please design them from a C point of
view, initially implemented by your Python functionality doing the
necessary wrapping to get a sane C structure.  Then they can be replaced
by native C code as RSI and time permits in the future.


-- 
Fabian Groffen
Gentoo on a different level