Progress with Batteries

[steve donovan]

Hi all,

ZBStudio debugging is now behaving sanely (see discussion at
https://github.com/LuaDist/batteries/issues/3) with a small patch from
Paul K.

I think what we need to do is collect the LfW docs and example trees
into a separate repo, and then Peter can merge that into his zip.

I've started making a manifest of all the LuaDist packages that are
binary compatible - the batteries have about 70 odd, but there's
nearly 100 other packages that can be directly installed from the
batteries with 'luadist install' (note: this doesn't require a
compiler, CMake or git to be installed) So I've started adding tags
to this manifest file, and then I can write a little wxLua app which
will allow users to download (and _upgrade_) any other compatible
LuaDist package.

steve d.

[Peter Drahoš]

On Mon, Mar 18, 2013 at 4:57 PM, steve donovan <steve.j...@gmail.com> wrote:

Hi all,

ZBStudio debugging is now behaving sanely (see discussion at
https://github.com/LuaDist/batteries/issues/3) with a small patch from
Paul K.

I think what we need to do is collect the LfW docs and example trees
into a separate repo, and then Peter can merge that into his zip

 

Great, the repo does not have to be complex. Just place all the docs into a directory and push to git repository so I can install it.

I've started making a manifest of all the LuaDist packages that are
binary compatible - the batteries have about 70 odd, but there's
nearly 100 other packages that can be directly installed from the
batteries with 'luadist install'  (note: this doesn't require a
compiler, CMake or git to be installed)  So I've started adding tags
to this manifest file, and then I can write a little wxLua app which
will allow users to download (and _upgrade_) any other compatible
LuaDist package.

 

Generating and keeping a manifest of modules will be essential. This came up multiple times in the discussions. For this we need the CI server which could generate it and keep it up to date (perhaps using a github gist so it does not need to serve it). This would open up some possibilities LuaDist currently cannot do efficiently. Eg. error help on require when packages are missing could point users to download the missing package using Michal Kottmans intellua. Steve already mentioned the wx based GUI frontend to the installer which could even integrate with ZeroBrane. Keyword search as suggested by Andrew etc. All these would rely on it so it makes sense to start with the manifest.

pd

[marbux]

On Tue, Mar 19, 2013 at 2:02 AM, Peter Drahoš <dra...@gmail.com> wrote:

> Generating and keeping a manifest of modules will be essential. This came up
> multiple times in the discussions. For this we need the CI server which
> could generate it and keep it up to date (perhaps using a github gist so it
> does not need to serve it). This would open up some possibilities LuaDist
> currently cannot do efficiently. Eg. error help on require when packages are
> missing could point users to download the missing package using Michal
> Kottmans intellua. Steve already mentioned the wx based GUI frontend to the
> installer which could even integrate with ZeroBrane. Keyword search as
> suggested by Andrew etc. All these would rely on it so it makes sense to
> start with the manifest.

I've been looking around the wiki but haven't found a firm answer to a
question: will embedders/end users be able to filter entries for
modules that are known to be incompatible with the version of Lua
installed/embedded?

That necessarily raises subordinate questions about what metadata is
required with a dist and an implementation setting in Steve's wxLua
front end (perhaps a command line argument?). I presume that the
supported version metadata would need to include an "unknown" option
for many existing modules.

Also a reminder that I would very much like to assist on writing
documentation for lay users. I'm a retired trial lawyer; much of a
trial lawyer's craft is effectively communicating unfamiliar concepts
to judges and juries. I have experience in writing software
documentation.

Best regards,

Paul

[Peter Drahoš]

On 19 Mar, 2013, at 19:13 , marbux <mar...@gmail.com> wrote:

> On Tue, Mar 19, 2013 at 2:02 AM, Peter Drahoš <dra...@gmail.com> wrote:
>
>> Generating and keeping a manifest of modules will be essential. This came up
>> multiple times in the discussions. For this we need the CI server which
>> could generate it and keep it up to date (perhaps using a github gist so it
>> does not need to serve it). This would open up some possibilities LuaDist
>> currently cannot do efficiently. Eg. error help on require when packages are
>> missing could point users to download the missing package using Michal
>> Kottmans intellua. Steve already mentioned the wx based GUI frontend to the
>> installer which could even integrate with ZeroBrane. Keyword search as
>> suggested by Andrew etc. All these would rely on it so it makes sense to
>> start with the manifest.
>
> I've been looking around the wiki but haven't found a firm answer to a
> question: will embedders/end users be able to filter entries for
> modules that are known to be incompatible with the version of Lua
> installed/embedded?

Yes and no. Not directly, LuaDist determines compatibility by walking the dependency list of the package being evaluated. This goes on for any package, not just Lua modules. All Lua modules have a dependency on Lua marked in their dist.info[1] which is used to check what Lua version it is compatible against. For source modules this works flawlessly but binaries are trickier as modules also need to know what ABI they were compiled against, that is currently not implemented but it is already worked on. Additionally modules that are known to be conflicting against other modules can be marked so [2].

Any module can be quickly evaluated against the list of installed packages to determine if it is compatible with the current setup, so the answer to your question is yes. However, we can not currently generate binaries for modules that are both Lua 5.1 and 5.2 compatible because of the above mentioned issue. So for now only Lua 5.1 binaries are available.

> That necessarily raises subordinate questions about what metadata is
> required with a dist and an implementation setting in Steve's wxLua
> front end (perhaps a command line argument?). I presume that the
> supported version metadata would need to include an "unknown" option
> for many existing modules.

Steve can access all the required functionality through the "dist" module which can be required from Lua directly. This includes functions that evaluate compatibility of the module against already deployed modules [3]. Required dist metadata is only "name" and "version" everything else is optional and any other entries can be present, however all Lua modules also contain dependency "depends = { lua .. }".

All Steve will need to display is a list of modules and their versions with a checkbox indicating if it can be installed into the current destination. Better yet it could use a simple option "filter by compatibility [x]" so you can hide incompatible modules and versions.

> Also a reminder that I would very much like to assist on writing
> documentation for lay users. I'm a retired trial lawyer; much of a
> trial lawyer's craft is effectively communicating unfamiliar concepts
> to judges and juries. I have experience in writing software
> documentation.

This is what I am terrible at so it would be great if someone would care of the introduction material such as basic use and explanation what LuaDist basically does without going into internals. This includes the material on the luadist.org page which is kept as minimal as possible because of this. The access to the Wiki is not restricted and anyone with a GitHub account can improve it.

pd

[1] https://github.com/LuaDist/luajit/blob/master/dist.info#L18 - Marks LuaJIT conflict with lua (they share liblua.so)
[2] https://github.com/LuaDist/luafilesystem/blob/master/dist.info#L13 - Marks luafilesystem compatible witj lua 5.1 and above
[3] https://github.com/LuaDist/luadist-git/blob/master/dist/init.lua#L71 - Dependency check in the install command uses "dist.depends" module