| 1 |
Am 18.06.2010 09:55, schrieb Brian Harring: |
| 2 |
> While I'm not generally a fan of embedding python, in this case it's |
| 3 |
> what makes sense. That said I'm not hugely convinced the proposal on |
| 4 |
> the table is accurate- knocking out a public portage API needs to |
| 5 |
> occur, but a c-api is a very large and seperate beast from a public |
| 6 |
> python API- namely due to crossing the vm, having to do FFI |
| 7 |
> conversions, etc. It's not the simplest thing. |
| 8 |
|
| 9 |
Well - there a tools like Cython which will take large parts of this |
| 10 |
burden from your shoulder. |
| 11 |
|
| 12 |
> For pkgkit, what I'd suggest is basically pushing into pkgkit just cpy |
| 13 |
> stubs that know to import a specific namespace, and grab functions |
| 14 |
> from there. It's been a while since I've gone through that code, but |
| 15 |
> if memory serves this shouldn't be too hard to do- the reasons for |
| 16 |
> doing this pretty much come down to allowing portage to minimize the |
| 17 |
> area it needs to provide a stable API for. |
| 18 |
> |
| 19 |
> If all it has to provide is a stable set of functors for pkgkit, |
| 20 |
> that leaves open fixing portage internals/architecture. |
| 21 |
|
| 22 |
I thought this was the whole idea of having such an API - providing a |
| 23 |
stable set of higher level functions, whose implementation can change if |
| 24 |
needed. |
| 25 |
|
| 26 |
Just pulling random portage functions into a new namespace is not a goal |
| 27 |
imho. |
| 28 |
|
| 29 |
- René |
Archives