[zypp-devel] next-gen API for package management?
ZYpp API is a toolkit. It provides not only the package management API but all the classes and components like a LEGO set. In this regard, its goals as an API are very similar to LLVM. This makes the API complex to wrap in scripting languages, both technically and from the user point of view: the wrapped API does not make much sense for simple tasks. However, we have seen the need for a simple client API that encapsulates all the knowledge there. Ideally this would be a simple API, comparable to what zypper offers, or what PackageKit offers. This API could actually be used by zypper and the PackageKit backend, which would serve as a good testbed for its usefulness. The API could be done in plain C, exposing only opaque structs keeping the ZYpp data and some API to do operations, but avoiding exposing other types that would conflict with scripting languages own stdlibs (Pathname, Date, etc), so restricting itself to basic types only. Having a simple C API would allow for easy binding: you can use swig, ffi, interpreter own API, etc. If we follow conventions like class_methodname(class *, args).. etc bindings get easier... Now, how this API would look like? Lets collect use cases. Where possible I would prefer actual client code examples in C, python, etc together with the use case (only usecases could lead to a committee-taste API). -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
* Duncan Mac-Vicar P. <dmacvicar@suse.de> [Aug 31. 2011 15:06]:
ZYpp API is a toolkit. It provides not only the package management API but all the classes and components like a LEGO set. In this regard, its goals as an API are very similar to LLVM.
This makes the API complex to wrap in scripting languages, both technically and from the user point of view: the wrapped API does not make much sense for simple tasks.
I couldn't agree more. [...]
Now, how this API would look like? Lets collect use cases. Where possible I would prefer actual client code examples in C, python, etc together with the use case (only usecases could lead to a committee-taste API).
Remember that we had this dicussion back in December last year. libzypp-bindings had a "new_api" branch created for this. But it needs active collaboration to evolve into something useful. Klaus --- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On 08/31/2011 03:18 PM, Klaus Kaempf wrote:
Remember that we had this dicussion back in December last year. libzypp-bindings had a "new_api" branch created for this. But it needs active collaboration to evolve into something useful.
Never heard of that branch before, and the only mention I could find is at the bottom of http://lists.opensuse.org/zypp-devel/2010-12/msg00003.html I would like to do some research on a clean base, and as I would like the same simple API to be fully supported from C, I believe putting the load in the bindings itself is not the way to go. I may be wrong, that is why I tried with some of the examples Pascal posted. A simple API will suffer because there are operations that are hard to do without granular access to the intermediate steps. But the solution here may be possible using a layered approach (like the lsyncd api). -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
participants (2)
-
Duncan Mac-Vicar P.
-
Klaus Kaempf