Re: [gentoo-portage-dev] [API] First steps for creating an API for portage

[Brian Harring]

On Fri, Jun 18, 2010 at 12:55:37PM +0200, Rennn 'Necoro' Neumann wrote:
> Am 18.06.2010 09:55, schrieb Brian Harring:
> > While I'm not generally a fan of embedding python, in this case it's
> > what makes sense.  That said I'm not hugely convinced the proposal on
> > the table is accurate- knocking out a public portage API needs to
> > occur, but a c-api is a very large and seperate beast from a public
> > python API- namely due to crossing the vm, having to do FFI
> > conversions, etc.  It's not the simplest thing.
>
> Well - there a tools like Cython which will take large parts of this
> burden from your shoulder.

Cython is for extending python, embedding python.  Cython doesn't do 
jack for embedding... frankly very little does.


> > For pkgkit, what I'd suggest is basically pushing into pkgkit just cpy
> > stubs that know to import a specific namespace, and grab functions
> > from there.  It's been a while since I've gone through that code, but
> > if memory serves this shouldn't be too hard to do- the reasons for
> > doing this pretty much come down to allowing portage to minimize the
> > area it needs to provide a stable API for.
> >
> > If all it has to provide is a stable set of functors for pkgkit,
> > that leaves open fixing portage internals/architecture.
>
> I thought this was the whole idea of having such an API - providing a
> stable set of higher level functions, whose implementation can change if
> needed.
>
> Just pulling random portage functions into a new namespace is not a goal
> imho.

Everything I've seen of the pkgkit hooks required for this, it's not a 
good api.  It's a good API for *pkgkit* which targets LCD, but that 
doesn't mean it's a good *portage* api to expose and maintain.

As such a portage provided/bundled shim is the best notion, at least 
until portage locks down a stable api it's willing to support rather 
than "sure, what we've got we'll call stable!".

~harring