From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9098 invoked from network); 19 Oct 2004 22:56:26 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 19 Oct 2004 22:56:26 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CK2u1-00013p-Gy for arch-gentoo-portage-dev@lists.gentoo.org; Tue, 19 Oct 2004 22:56:25 +0000 Received: (qmail 10406 invoked by uid 89); 19 Oct 2004 22:56:23 +0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@lists.gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 7767 invoked from network); 19 Oct 2004 22:56:23 +0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <200410172001.37303.jstubbs@gentoo.org> <1098030320.8046.19.camel@localhost> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1524F9A6-2222-11D9-961E-000D93340F82@web.de> Content-Transfer-Encoding: 7bit From: Daniel Taylor Date: Tue, 19 Oct 2004 18:56:16 -0400 To: gentoo-portage-dev@lists.gentoo.org X-Mailer: Apple Mail (2.619) Sender: dantaylor@web.de X-Sender: dantaylor@web.de Subject: Re: [gentoo-portage-dev] Portage API X-Archives-Salt: d37de726-9962-4d74-9bfc-6ba69a64ad75 X-Archives-Hash: 5621a56fd9432a99d3c99d165e8bd7dc 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