[lxc-devel] [PATCH] Rewrite lxc-ls in python

[Stéphane Graber]

On 11/22/2012 08:39 AM, Natanael Copa wrote:
> On Wed, 21 Nov 2012 18:04:03 -0500
> Stéphane Graber <stgraber at ubuntu.com> wrote:
> 
>> This rewrite is mostly compatible with the shell version.
>> --active and -1 still work and behave as they used to.
> 
> Does this mean that python will be a requirement for lxc in future? I
> am currently working on switching things from vserver, partially
> because lxc has opened for less required dependencies on the host.
> 
> Currently an Alpine Linux lxc host with base + lxc installed is 6.9MB
> excluding kernel. A corresponding vserver host is 11.6MB.
> 
> Python is 37MB.
> 
> Do we really need this bloat?
> 
> -nc

So let me give some background on what we're trying to do here :)

The past 6 months Serge and I have been working on liblxc which has now
landed in staging for quite some time.
The goal for this library is to offer simple and intuitive access to all
the LXC functions.

We are now in the process of replacing the old code (C and shell alike)
to use the liblxc API so we can clear out some old code from the tree.

The new code will have a very similar structure and close to no
lxc-specific logic in it as everything will be done by the API.

As the library itself is in C, you need bindings to use it in scripting
languages. I wrote one such binding for python3 which I'm now using in a
few scripts (lxc-start-ephemeral and lxc-ls for now, there are a couple
more to come over the next few days).

Technically, porting to the API at the moment can either be done in C or
python. As LXC doesn't use any of the fancy C libraries like glib to
make the developer's life easier, the easiest way to code something
nowadays is with python.


I perfectly realize that this means we'll start depending on python3
(core only, no extra modules) for our tools and I don't really think
it'll be a problem for > 90% of our users, most of which will probably
like being able to reuse that code in their own script and be able to
easily extend our tools.


Now for the remaining < 10%, I think it'd be interesting to write a tool
in C, that'd be a very thin layer on top of liblxc and which could be
used instead of the regular tools on systems were installation size is a
concern.
I wouldn't expect that tool to do any of the fancy output, filtering or
really any advanced feature we have in the new python tools, but it'd
let you create/start/stop/list containers.

I'm not saying, I'll write this tool, but I'm saying this sounds like a
reasonable, maintainable option for the future and we could also use
that tool as a test of the C API.


-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20121122/3782ebd5/attachment.pgp>