deploy lubyk through luadist

[Gaspard Bucher]

Hi there,

I would like to let lua users easily install core parts of lubyk but before moving forward, I have one important issue that I want to be sure can be handled by luadist:

How are assets (template files, images, etc) managed ?

Actually, I install these along the lua source files (like rubygems does) and this makes finding them very easy, portable and relocatable.

How does luadist handle this ?

Thanks for your support.

Gaspard

------------

project: http://lubyk.org

documentation: http://doc.lubyk.org

[Peter Drahoš]

Hello,
LuaDist more or less follows unix style of software deployment.
Packages are installed into /bin /lib /include /share etc. Package
data is usually stored in /share/[package] using the install_data ( )
macro[1]. In that directory the structure is up to you.

On Tue, Apr 2, 2013 at 1:08 PM, Gaspard Bucher <gas...@teti.ch> wrote:
> Hi there,
>
> I would like to let lua users easily install core parts of lubyk but before
> moving forward, I have one important issue that I want to be sure can be
> handled by luadist:
>
> How are assets (template files, images, etc) managed ?

The recommended approach is to install to /share/[package] but
installing alongside Lua modules is acceptable also.

> Actually, I install these along the lua source files (like rubygems does)
> and this makes finding them very easy, portable and relocatable.

Yes, indeed this has advantages but also some disadvantages. The
primary advantage is that the files are easy to locate using
package.path. The disadvantage is that this makes the installations
messier and limits automated processing of lua modules using automated
tools to some extent.

> How does luadist handle this ?

I prefer to install into /share/[package], from within Lua the path to
the LuaDist deployment directory is as follows:

local paths = {}
package.path:gsub("([^;]+)", function(c) table.insert(paths, c) end)
local path = paths[2]:gsub("[/\\]bin[/\\]%.%..*","")

LuaDist does provide utility function to obtain the directory also but
the above snippet removes the requirement to have luadist-git package
installed. From within that path you can access /share/[package] as
usual.

If you intend to pack an application rather then lua modules please
have a look at zerobranestudio and its launcher[2].

pd

[1] https://github.com/LuaDist/zerobranestudio/blob/master/CMakeLists.txt#L13
[2] https://github.com/LuaDist/zerobranestudio/blob/master/zbstudio.lua

[Peter Drahoš]

I had a look at the source repository. I think I understand your
situation better now. I see the the project aggregates a fair amount
of dependencies. Some of these are already in LuaDist, some can be
added directly from Lubyk. Seems like an interesting project that
could certainly benefit from the integration.

I recommend first to separate the submodule dependencies into separate
modules. Once that is done the Lubyk package can use LuaDist to manage
its dependencies.

The project peeked my interest and I can spare some time to integrate
it if you want me to.

pd

[Gaspard Bucher]

Hi Peter,

Thanks for the nice email. I am actually removing most of the cross-module dependencies and refactoring some compatibility classes for matrix, vectors and such so that each module only needs to know about core parts.

Actually, my concern is to handle a situation where installed lua code behaves the same as "local" lua code thus not needing to "make install" while developing. This is currently done by adding some paths to package.path. If I move files away from lua code (in /usr/share/lubyk for example), this will work once installed but not locally nor when deployed as a single "Lubyk.app" where all content is in "/Applications/Lubyk.app/Contents/Resources/lib".

If I can have a few templates and CSS files in lua's directory, then all is easy and well.

Gaspard Bucher

------------

founder, coder

teti sàrl

--

You received this message because you are subscribed to the Google Groups "LuaDist" group.

To unsubscribe from this group and stop receiving emails from it, send an email to luadist+u...@googlegroups.com.

To post to this group, send email to lua...@googlegroups.com.

Visit this group at http://groups.google.com/group/luadist?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.

[marbux]

On Tue, Apr 2, 2013 at 7:33 AM, Gaspard Bucher <gas...@teti.ch> wrote:

> If I can have a few templates and CSS files in lua's directory, then all is
> easy and well.

That could conceivably raise issues when LuaDist is embedded along
with Lua in other C programs, which we will likely do soon after
LuaDist is ready for embedded Lua 5.2. Please consider the embedded
LuaDist scenario carefully here.

This might be acceptable if only one or two modules do this but I can
see it dissembling into disorder if many modules follow suit. E.g., on
Windows, we already ship the Lua.dll in an "app" directory along with
a host of other executables. I'm not certain what we do in relevant
regard on other supported platforms, since we do nearly all of our
development builds on Windows. But cramming the same directory with
non-executables doesn't seem attractive at first blush.

Best regards,

Paul

[Gaspard Bucher]

I agree, but the need for a few "assets" or templates is very rare. Among all modules in lubyk, this is the only need... Other assets can perfectly live in a "shared" folder as they are only used for example/documentation. This case is particular because the generated docs are.. unreadable without the proper CSS and JS scripts.

The embedding question is important but in this case the documentation generator will never be used and can be removed along with the "doc" files.

Gaspard

Best regards,

Paul

[marbux]

On Tue, Apr 2, 2013 at 1:45 PM, Gaspard Bucher <gas...@teti.ch> wrote:

> The embedding question is important but in this case the documentation
> generator will never be used and can be removed along with the "doc" files.

Might those be done as separate packages? We'd very much like our
users not to need to deal with issues such as removing files. It's
not unlikely that some of our users will want to use lubyk in scripts
and plugins; we support audio recording and playback and have methods
in our API for audio support; we're planning to add more.

Best regards,

Paul

[Gaspard Bucher]

I am already using "lubyk" in vst plugins so I perfectly understand the worry about non-embeddable files.

Argggg, I thought I had split this code into small enough parts. Damn.

But then, what needs to go into the core ?

The scheduler ? Not needed by all projects.

Serialization ? Not needed by non-network based modules.

Zeroconf ? Not needed by non-network based modules.

Templates ? Not needed everywhere.

You see my point ? I feel like this module will just be empty.

Since most "high level" modules need the Scheduler and Serialization these will probably go into "lub".

I will move "testing" and "documenting" into "lut" (lubyk utilities) so that "lub" only contains ".cpp" and ".lua" files and things needed at runtime.

Cheers,

Gaspard

[marbux]

On Tue, Apr 2, 2013 at 2:37 PM, Gaspard Bucher <gas...@teti.ch> wrote:

> You see my point ? I feel like this module will just be empty.

Yes. These are not easy choices.

> Since most "high level" modules need the Scheduler and Serialization these
> will probably go into "lub".
>
> I will move "testing" and "documenting" into "lut" (lubyk utilities) so that
> "lub" only contains ".cpp" and ".lua" files and things needed at runtime.

Sounds like a logical grouping to me. Thanks for taking the time to
think about the issue I raised and adjusting accordingly. I appreciate
that.

Best regards,

Paul

[Gaspard Bucher]

Sounds like a logical grouping to me. Thanks for taking the time to

think about the issue I raised and adjusting accordingly. I appreciate

that.

You welcome, more brains, less pains.

I created the CMakeLists.txt files for "lub" and "lut":

https://github.com/lubyk/lub

https://github.com/lubyk/lut

Please let me know if all looks ok.

Cheers,

Gaspard

[Peter Drahoš]

Added with minor fixes which you can pull back if you want to. On
update just post a pull request.

Thank you.

pd

[Gaspard Bucher]

Hi Peter,

Thanks for your help. I just pulled your changes back into "lub" and "lut".

Concerning luadist installation, why hasn't anyone created a debian package ?

apt-get install luadist  /  brew install luadist

luadist install xyz

Cheers,

Gaspard

[Peter Drahoš]

Good question,
well there really is no need to. If you keep it localized at your home
directory you do not need another package manager. You can install
LuaDist using LuaDist, just bootstrap the 1st one and 'luadist
/home/me/LuaDist2 install luadist-git'.

It sure would be more convenient to have a system provided one.

pd