| 1 |
Hey, |
| 2 |
|
| 3 |
Glad to see you got a hold of Fredrik. He knows far more about Portage |
| 4 |
internals and what we are using than anyone else, even if he hasn't |
| 5 |
worked with Porthole for a while! |
| 6 |
|
| 7 |
Note that what follows are the rantings of someone who will probably |
| 8 |
not be using Portage or Porthole anymore, so take it as you will. |
| 9 |
|
| 10 |
Now, as Brian and Fredrik have answered many of the questions and |
| 11 |
pointed out what and why in their replies, I'll talk about my take on |
| 12 |
the whole issue. I think there are a few issues that need to be |
| 13 |
addressed for the API to work. |
| 14 |
|
| 15 |
Currently, interfacing with Portage is complicated. The Portage |
| 16 |
internals aren't very documented, and much of the code is far from |
| 17 |
self-documenting (check out the dependency stuff, I still don't get |
| 18 |
it!). I do realize the point of the API is to have a well documented, |
| 19 |
standard way of interfacing with Portage, so I see the API as a |
| 20 |
solution to this issue. This is why I was bugging you so much, Jason ;) |
| 21 |
|
| 22 |
Everytime that Porthole does anything other than load package |
| 23 |
information, and external script (emerge) is run. This seems a bit |
| 24 |
inefficient, when we already have Portage loaded in memory as a module. |
| 25 |
What I think would be much more convenient and perhaps provide more |
| 26 |
functionality would be to emerge through the API; |
| 27 |
portage.emerge(app_name, pipe), where pipe would allow reading output |
| 28 |
and entering input (if a question needs to be answered or something). |
| 29 |
You should be able to internally streamline this process so that |
| 30 |
another instance of Portage doesn't need to be loaded. This principle |
| 31 |
applies to other functions, such as syncing, as well. |
| 32 |
|
| 33 |
From what I remember of the docs you showed me for the now defunct API, |
| 34 |
everything was a bit obscure. You emerged or pretended based on which |
| 35 |
tree was sent to a function (from what I understood of it, anyway). |
| 36 |
These functions should be made as easy to understand for new developers |
| 37 |
as can be. They should try to be self-explanatory. |
| 38 |
|
| 39 |
This isn't part of the API, but I thought I'd mention it. Portage is |
| 40 |
notorious for not being internationalized. I did a mockup of a gconf- |
| 41 |
and GNOME-using, il8n-ized, HIGified, multi-backend Porthole just a few |
| 42 |
weeks back. I think Brian is adding il8n to the current codebase. Even |
| 43 |
if we were to support il8n, package descriptions and various output |
| 44 |
would all only be available in English. This needs to change. |
| 45 |
|
| 46 |
One thing that really impressed me with the API you were working on is |
| 47 |
that you used it to make an 'emerge' script that acted just like the |
| 48 |
official one. This is how this stuff needs to be done. Portage should |
| 49 |
just be a library, and it should contain (and export) all of the |
| 50 |
functionality for the system to function properly (managing packages |
| 51 |
and information, updating, whatever). All tools that are written should |
| 52 |
use the API. This puts more force behind putting core functionality in |
| 53 |
the library instead of the scripts, which is a pain at the moment (take |
| 54 |
a look at emerge). |
| 55 |
|
| 56 |
Well, enough ranting for now. I'm sure I am wrong about some of these |
| 57 |
points, so be gentle ;-) |
| 58 |
-- |
| 59 |
Daniel G. Taylor |
| 60 |
http://programmer-art.org |
| 61 |
|
| 62 |
|
| 63 |
-- |
| 64 |
gentoo-portage-dev@g.o mailing list |
Archives