Gentoo Archives: gentoo-portage-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] [API] First steps for creating an API for portage
Date: Fri, 18 Jun 2010 08:03:40
Message-Id: 20100618075558.GC12490@hrair
In Reply to: Re: [gentoo-portage-dev] [API] First steps for creating an API for portage by Fabian Groffen
1 On Fri, Jun 18, 2010 at 08:35:13AM +0200, Fabian Groffen wrote:
2 > On 18-06-2010 02:08:04 +0200, René 'Necoro' Neumann wrote:
3 > > In parallel (or thereafter), we build the C-bindings. The API for these
4 > > bindings probably look different -- but I guess they should be
5 > > implemented in terms of the library created above.
6 > >
7 > > By example:
8 > >
9 > > - Operation: get the list of categories
10 > > - Python-API: portage.api.categories() : Category list
11 > > - Implementation: def categories(): return ....
12 > > - C-API: category * categories()
13 > > - C-Implementation: some wrapper around portage.api.categories
14 >
15 > If you want to deliver a C implementation, I'd wonder why you wouldn't
16 > just make a full C implementation and create Python wrappers for them
17 > instead of the other way around. Might accidentially speed up Portage,
18 > and make tools like portage-utils happy.
20 Got a couple of years of developer time you can spare? ;)
22 Portage's slowness ain't python, if in doubt look at pkgcore. Even
23 w/out our extensions we blow it's lid off. So kindly skip the "it'll
24 be faster in c" bits... that joke is beyond dead at this point ;)
26 back to the subject at hand...
28 While I'm not generally a fan of embedding python, in this case it's
29 what makes sense. That said I'm not hugely convinced the proposal on
30 the table is accurate- knocking out a public portage API needs to
31 occur, but a c-api is a very large and seperate beast from a public
32 python API- namely due to crossing the vm, having to do FFI
33 conversions, etc. It's not the simplest thing.
35 For pkgkit, what I'd suggest is basically pushing into pkgkit just cpy
36 stubs that know to import a specific namespace, and grab functions
37 from there. It's been a while since I've gone through that code, but
38 if memory serves this shouldn't be too hard to do- the reasons for
39 doing this pretty much come down to allowing portage to minimize the
40 area it needs to provide a stable API for.
42 If all it has to provide is a stable set of functors for pkgkit,
43 that leaves open fixing portage internals/architecture.
45 My two cents either way. I know for pkgcore/pkgkit, this is my
46 intention also...
48 ~harring


Subject Author
Re: [gentoo-portage-dev] [API] First steps for creating an API for portage "René 'Necoro' Neumann" <lists@××××××.eu>