On Sun, 2005-03-06 at 14:27 +0900, Chris White wrote:
> Ok, since it was asked of by jstubbs, time to get some stuff rolling as
> to API requirements.
Very good idea.
I'm looking at it especially from a "tinderbox" (automated building)
point of view

- generic get/set access to all config options
We need to be able to generate a pre-defined environment for building

- interface to the depgraph
For certain operations, including build parallelization, we need a local
copy of all dependency information. Also, repoman might be able to be a
wrapper for this interface?

- access to ebuild.sh functions, e.g. tell portage "unpack and patch
foobar-1.2 for me"

> 1) repository can be more than just a standard abiding set of files.
> Maybe a custom repository, or a relational database.
That's backend and independent of the "outside" API

> 2) access to an internal download library built into portage (not wget
> or some such).  This would not only allow us to do basic downloading,
> but also address new protocols that come later on.
Excellent idea. afaik this idea is being implemented as "transports"?

> 3) ability to access certain information regarding package environment
> (CFLAGS, USE, etc.), which when trying to get this information, has been
> stated as "unclean" in case the methods change later on (ie. pulling
> from /var/pkg/db/category/package/USE I was told was a bad idea for some
> reason).
Does that differ from my idea for a generic config interface?

>   If portage can do it cleanly internally, an api should be able
> to tap into that and give us something more solid to work with.  This
> should also help in getting rid of those pesky "Did my package get
> compiled with this use flag" requests.
> 
> 4) a searching API to look for certain packages.  This sort of goes hand
> in  hand with #1, as it gives the ability for someone to get mysql
> querying to acccess a mysql repository.
I'd like to keep those two things separated.
From a user p.o.v. the backend (flat files, db, pigeons) should be
transparent. I think searching based on atoms, descriptions etc. would
be best, the SQL interface might be documented separately ...

> 5) Better info on SRC_URI's, including total size, downloaded size,
> md5's, blah blah,etc etc.  Somewhat goes hand in hand with #4.
> 
> 6) An output api which would help in supporting gui displaying as well
> as ncurses or anything else where one chooses that they want to put
> stuff.  Also, I'd like for a localization support feature in here
> (localized strings basically).  This would help in portage localization.
erm ...
that's not what the API does.
The API only gives you access to portage internals. Your GUI gets
wrapped around that so that any GUI uses the same communication
primitives.

Basically all your GUI needs to do should be:
import portage
blah=portage #blah is an instance of portage
blah.init()  # initialize that instance

then work with that.


> That's all that's on my mind for now.  Please let me know if I need to
> be clearer with some of my ideas.  Please feel free to put your 2
> $country_coin_denomiation_value in to make this another meaningful
> discussion.
I think you should get the frontend and the backend separated.
My GUI doesn't care about your SQL backend. Your SQL backend doesn't
care about my OpenGL GUI. 
Otherwise I think your first rough draft looks good.

wkr,
Patrick