| 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. |
| 19 |
|
| 20 |
Got a couple of years of developer time you can spare? ;) |
| 21 |
|
| 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 ;) |
| 25 |
|
| 26 |
back to the subject at hand... |
| 27 |
|
| 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. |
| 34 |
|
| 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. |
| 41 |
|
| 42 |
If all it has to provide is a stable set of functors for pkgkit, |
| 43 |
that leaves open fixing portage internals/architecture. |
| 44 |
|
| 45 |
My two cents either way. I know for pkgcore/pkgkit, this is my |
| 46 |
intention also... |
| 47 |
|
| 48 |
~harring |
Archives