Re: [gentoo-portage-dev] Portage API

[Daniel Taylor <dantaylor@web.de>]

Hey,

Glad to see you got a hold of Fredrik. He knows far more about Portage 
internals and what we are using than anyone else, even if he hasn't 
worked with Porthole for a while!

Note that what follows are the rantings of someone who will probably 
not be using Portage or Porthole anymore, so take it as you will.

Now, as Brian and Fredrik have answered many of the questions and 
pointed out what and why in their replies, I'll talk about my take on 
the whole issue. I think there are a few issues that need to be 
addressed for the API to work.

Currently, interfacing with Portage is complicated. The Portage 
internals aren't very documented, and much of the code is far from 
self-documenting (check out the dependency stuff, I still don't get 
it!). I do realize the point of the API is to have a well documented, 
standard way of interfacing with Portage, so I see the API as a 
solution to this issue. This is why I was bugging you so much, Jason ;)

Everytime that Porthole does anything other than load package 
information, and external script (emerge) is run. This seems a bit 
inefficient, when we already have Portage loaded in memory as a module. 
What I think would be much more convenient and perhaps provide more 
functionality would be to emerge through the API; 
portage.emerge(app_name, pipe), where pipe would allow reading output 
and entering input (if a question needs to be answered or something). 
You should be able to internally streamline this process so that 
another instance of Portage doesn't need to be loaded. This principle 
applies to other functions, such as syncing, as well.

 From what I remember of the docs you showed me for the now defunct API, 
everything was a bit obscure. You emerged or pretended based on which 
tree was sent to a function (from what I understood of it, anyway). 
These functions should be made as easy to understand for new developers 
as can be. They should try to be self-explanatory.

This isn't part of the API, but I thought I'd mention it. Portage is 
notorious for not being internationalized. I did a mockup of a gconf- 
and GNOME-using, il8n-ized, HIGified, multi-backend Porthole just a few 
weeks back. I think Brian is adding il8n to the current codebase. Even 
if we were to support il8n, package descriptions and various output 
would all only be available in English. This needs to change.

One thing that really impressed me with the API you were working on is 
that you used it to make an 'emerge' script that acted just like the 
official one. This is how this stuff needs to be done. Portage should 
just be a library, and it should contain (and export) all of the 
functionality for the system to function properly (managing packages 
and information, updating, whatever). All tools that are written should 
use the API. This puts more force behind putting core functionality in 
the library instead of the scripts, which is a pain at the moment (take 
a look at emerge).

Well, enough ranting for now. I'm sure I am wrong about some of these 
points, so be gentle ;-)
--
Daniel G. Taylor
http://programmer-art.org


--
gentoo-portage-dev@gentoo.org mailing list