Hi,

Som things I have been thinking of for some time.

It would be nice to make apk-tools functions available from other
applications and higher level languages. The immedeate need I have is
a binding to the version compare functions from lua. In the longer run
it would be nice to be able to make a gui installer and have a nice
gui progress bar while installing. The point is that we will sooner or
later need to bind to apk from other applications.

We have some alternatives:
1. we can make a dynamic libapk.so and have the apk application link
to it and have the lua apk.so to link to it too. Less dupe of code.
2. we can dup the code. A build target uses same code but builds a lua
apk.so or similar.
3. we can have lua library fork/exec the current apk and parse the
output. I don't like this, specially not for sorting scripts that
needs compare version strings.

When it comes to the initramfs installer, we already need libcrypto,
libz, libc and openssl (for encrypted apkovls) in the initramfs image
so adding another lib doesnt really matter. (we could make an initapk
tool which links libc and libapk statically but libcrypt and libc
dynamic)

-- 
Natanael Copa


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

On 03/02/2010 03:44 AM, Timo Teräs wrote:
> Natanael Copa wrote:
>> Som things I have been thinking of for some time.
>>
>> It would be nice to make apk-tools functions available from other
>> applications and higher level languages. The immedeate need I have is
>> a binding to the version compare functions from lua. In the longer run
>> it would be nice to be able to make a gui installer and have a nice
>> gui progress bar while installing. The point is that we will sooner or
>> later need to bind to apk from other applications.
>>
>> We have some alternatives:
>> 1. we can make a dynamic libapk.so and have the apk application link
>> to it and have the lua apk.so to link to it too. Less dupe of code.
>> 2. we can dup the code. A build target uses same code but builds a lua
>> apk.so or similar.
>> 3. we can have lua library fork/exec the current apk and parse the
>> output. I don't like this, specially not for sorting scripts that
>> needs compare version strings.
>>
>> When it comes to the initramfs installer, we already need libcrypto,
>> libz, libc and openssl (for encrypted apkovls) in the initramfs image
>> so adding another lib doesnt really matter. (we could make an initapk
>> tool which links libc and libapk statically but libcrypt and libc
>> dynamic)
>
> From size point of view, option 1 is best. Though, currently apk
> library will not be that large so option 2 is ok too. Option 3 is
> not a good idea from performance point of view.
>
> However 1&2 do require that we start to maintain some sort of
> stable API. At least for the high level stuff the lua code wants
> to do.
>

A couple thoughts on this.

I like how easy lua is to embed into the app itself with no external
dependencies. Because apk is very small to start with that will add
considerable size to the executable (100K-300K I think).
This would allow us to write even some core functionality of apk in lua.
I believe you can also compile lua scripts directly into the executable
- size is bigger, but makes for easier development and changes.
This also allows writing plugins directly in lua, and just dropping them
in some directory to extend the functionality of apk.

That's all a bit different than having an app use apk. I've used swig
(http://www.swig.org/) before, and I like how it can create bindings for
several languages (lua, python, perl, php, ruby, etc) from one swig
config file that basically defines the API. These bindings could all be
in their own apk packages and be depended upon by any apps that want to
use them. These bindings can be compiled into their .so files from the
same source files that apk is compiled from, so there wouldn't really be
much duplication of code.

There are other tools like swig out there, swig is just the only one
I've personally used before.

-Cameron


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Natanael Copa wrote:
> Som things I have been thinking of for some time.
> 
> It would be nice to make apk-tools functions available from other
> applications and higher level languages. The immedeate need I have is
> a binding to the version compare functions from lua. In the longer run
> it would be nice to be able to make a gui installer and have a nice
> gui progress bar while installing. The point is that we will sooner or
> later need to bind to apk from other applications.
> 
> We have some alternatives:
> 1. we can make a dynamic libapk.so and have the apk application link
> to it and have the lua apk.so to link to it too. Less dupe of code.
> 2. we can dup the code. A build target uses same code but builds a lua
> apk.so or similar.
> 3. we can have lua library fork/exec the current apk and parse the
> output. I don't like this, specially not for sorting scripts that
> needs compare version strings.
> 
> When it comes to the initramfs installer, we already need libcrypto,
> libz, libc and openssl (for encrypted apkovls) in the initramfs image
> so adding another lib doesnt really matter. (we could make an initapk
> tool which links libc and libapk statically but libcrypt and libc
> dynamic)

>From size point of view, option 1 is best. Though, currently apk
library will not be that large so option 2 is ok too. Option 3 is
not a good idea from performance point of view.

However 1&2 do require that we start to maintain some sort of
stable API. At least for the high level stuff the lua code wants
to do.

But sounds good to me.

- Timo




---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

2010/3/2 Cameron Banta <cbanta@gmail.com>:
> On 03/02/2010 03:44 AM, Timo Teräs wrote:
>> Natanael Copa wrote:
>>> Som things I have been thinking of for some time.
>>>
>>> It would be nice to make apk-tools functions available from other
>>> applications and higher level languages. The immedeate need I have is
>>> a binding to the version compare functions from lua.
...
>> However 1&2 do require that we start to maintain some sort of
>> stable API. At least for the high level stuff the lua code wants
>> to do.


> A couple thoughts on this.
>
> I like how easy lua is to embed into the app itself with no external
> dependencies. Because apk is very small to start with that will add
> considerable size to the executable (100K-300K I think).
> This would allow us to write even some core functionality of apk in lua.
> I believe you can also compile lua scripts directly into the executable
> - size is bigger, but makes for easier development and changes.
> This also allows writing plugins directly in lua, and just dropping them
> in some directory to extend the functionality of apk.

I'm not sure we want pull in lua in the apk core code. I'm more
interested in having a c library with lua bindings than embedding lua
in the apk executable. (lua is good at the latter though)

> That's all a bit different than having an app use apk. I've used swig
> (http://www.swig.org/) before, and I like how it can create bindings for
> several languages (lua, python, perl, php, ruby, etc) from one swig
> config file that basically defines the API. These bindings could all be
> in their own apk packages and be depended upon by any apps that want to
> use them. These bindings can be compiled into their .so files from the
> same source files that apk is compiled from, so there wouldn't really be
> much duplication of code.
>
> There are other tools like swig out there, swig is just the only one
> I've personally used before.

lua bindings to c libs is pretty easy, even without swig and i think
swig gives you even more overhead.

The big thing here though is a timo say, a more or less stable api for
the library. What do we want high level langs should be able to do?

-- 
Natanael Copa


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---