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 18:03:29
Message-Id: 20100618170845.GE12490@hrair
In Reply to: Re: [gentoo-portage-dev] [API] First steps for creating an API for portage by "René 'Necoro' Neumann"
1 On Fri, Jun 18, 2010 at 12:55:37PM +0200, Rennn 'Necoro' Neumann wrote:
2 > Am 18.06.2010 09:55, schrieb Brian Harring:
3 > > While I'm not generally a fan of embedding python, in this case it's
4 > > what makes sense. That said I'm not hugely convinced the proposal on
5 > > the table is accurate- knocking out a public portage API needs to
6 > > occur, but a c-api is a very large and seperate beast from a public
7 > > python API- namely due to crossing the vm, having to do FFI
8 > > conversions, etc. It's not the simplest thing.
9 >
10 > Well - there a tools like Cython which will take large parts of this
11 > burden from your shoulder.
13 Cython is for extending python, embedding python. Cython doesn't do
14 jack for embedding... frankly very little does.
17 > > For pkgkit, what I'd suggest is basically pushing into pkgkit just cpy
18 > > stubs that know to import a specific namespace, and grab functions
19 > > from there. It's been a while since I've gone through that code, but
20 > > if memory serves this shouldn't be too hard to do- the reasons for
21 > > doing this pretty much come down to allowing portage to minimize the
22 > > area it needs to provide a stable API for.
23 > >
24 > > If all it has to provide is a stable set of functors for pkgkit,
25 > > that leaves open fixing portage internals/architecture.
26 >
27 > I thought this was the whole idea of having such an API - providing a
28 > stable set of higher level functions, whose implementation can change if
29 > needed.
30 >
31 > Just pulling random portage functions into a new namespace is not a goal
32 > imho.
34 Everything I've seen of the pkgkit hooks required for this, it's not a
35 good api. It's a good API for *pkgkit* which targets LCD, but that
36 doesn't mean it's a good *portage* api to expose and maintain.
38 As such a portage provided/bundled shim is the best notion, at least
39 until portage locks down a stable api it's willing to support rather
40 than "sure, what we've got we'll call stable!".
42 ~harring


Subject Author
Re: [gentoo-portage-dev] [API] First steps for creating an API for portage Brian Harring <ferringb@×××××.com>