Is there a place to look for a lua-resty module

[Jerome Lafon]

Hello,

Is there a place (website, repository or something else) where all the lua-resty-... modules are declared, with a small description or some keywords in order to do some searches?

If not, @agentz: would it be possible to add an in the openresty website in the menu located on the left named for instance "lua-resty contributions" with only 3 columns : name / short description / link

It would be very useful instead of coding some features even if a module already do it but we don't know the existence of this module.

Regards

Jerome

[Yichun Zhang (agentzh)]

Hello!

On Tue, Oct 28, 2014 at 11:01 AM, Jerome Lafon wrote:
> Is there a place (website, repository or something else) where all the
> lua-resty-... modules are declared, with a small description or some
> keywords in order to do some searches?
>

Not yet. I'm going to set up the luaresty.org site for hosting
lua-resty-* libraries like CPAN.

> If not, @agentz: would it be possible to add an in the openresty website in
> the menu located on the left named for instance "lua-resty contributions"
> with only 3 columns : name / short description / link
>

Sounds like a good start for now. Will you contribute a patch to the
site? Its source is on github:

https://github.com/openresty/openresty.org

You'll need a Firefox to edit the .html file locally. It's TiddlyWiki.
And yes, I have also had plans to rewrite this site using OpenResty
and to turn it into a real wiki such that authorized people can edit
it online.

> It would be very useful instead of coding some features even if a module
> already do it but we don't know the existence of this module.
>

Very true :)

Regards,
-agentzh

[Aapo Talvensaari]

On Tuesday, 28 October 2014 20:01:28 UTC+2, Jerome Lafon wrote:

Is there a place (website, repository or something else) where all the lua-resty-... modules are declared, with a small description or some keywords in order to do some searches?

The best place is probably (for now):

https://github.com/search?l=Lua&p=1&q=lua-resty+in%3Aname&ref=searchresults&type=Repositories&utf8=%E2%9C%93 

[Jerome Lafon]

I will provide a patch soon to add a entry in the menu and a dedicated page which lists all the know lua-resty modules.

But it's true that without a possibility to let authorized people to edit this page perhaps it will be deprecated quickly.

Jerome

[Jerome Lafon]

I did a search on google and most of the lua-resty modules are hosted on github but some of them not.

It's a pity to loose time finding them.

Jérôme

[Jerome Lafon]

A last point: it would be also very useful to write a "guidelines and best practices to write lua-resty modules" with:

- a very simple lua-resty module example written as a static module, which details the module parts, like the lua-resty-string

- a very simple lua-resty module example written as a class, which details the module parts, like the lua-resty-redis or even more simpler is possible

- a very simple lua-resty module example written using FFI in order to call external C libraries. 

- some generic advices in order to provide a efficient and improved module

May someone provide this documentation? (I don't have enough experience in Lua coding to provide a comprehensive documentation with all the useful examples and best advices for writing an efficient module)

Thanks

Jerome

[Yichun Zhang (agentzh)]

Hello!

On Wed, Oct 29, 2014 at 2:58 AM, Jerome Lafon wrote:
> A last point: it would be also very useful to write a "guidelines and best
> practices to write lua-resty modules" with:
> - a very simple lua-resty module example written as a static module, which
> details the module parts, like the lua-resty-string
> - a very simple lua-resty module example written as a class, which details
> the module parts, like the lua-resty-redis or even more simpler is possible
> - a very simple lua-resty module example written using FFI in order to call
> external C libraries.
> - some generic advices in order to provide a efficient and improved module
>

+1

I always mean to write such tutorials and demos but I always have a
problem with time :)

Contributions welcome! I always have the time to review though :)

Best regards,
-agentzh

[Vladislav Manchev]

Here are two examples of really simple FFI bindings:

https://github.com/bungle/lua-resty-murmurhash2/blob/master/lib/resty/murmurhash2.lua
https://github.com/blablacio/lua-bcrypt/blob/master/bcrypt.lua

Best,
Vladislav

--
You received this message because you are subscribed to the Google Groups "openresty-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openresty-en...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jerome Lafon]

Thank you. I keep the bcrypt lib as a FFI example in the doc part.

Jerome

[leaf corcoran]

Regarding a place to host  modules, there is a Lua package manager called LuaRocks: http://luarocks.org/

I've put putting all of my resty compatible modules there.

Additionally I created and run the main repository for LuaRocks modules: https://rocks.moonscript.org/ (written in openresty)

I spoke with agentzh briefly about using it, but I'd be glad to set something up to make it easier to find and share resty modules.

[Jerome Lafon]

It could be a good option.

Now the question is what to choose? luarocks or github?

There's a lot of lua-resty modules hosted on github, so if luarocks would be chosen the lua-resty modules owners should migrate their modules on luarocks. Is it an easy and simple task?

Jérôme

[Aapo Talvensaari]

On Monday, 3 November 2014 11:22:29 UTC+2, Jerome Lafon wrote:

It could be a good option.

Now the question is what to choose? luarocks or github?

Well, I don't think about whether it is LuaRocks vs. Github. I have made rocks in rocks.moonscript.org for those lua-resty-* modules that I do considerate documented and fully functional, e.g. https://rocks.moonscript.org/manifests/bungle/lua-resty-template-1.2-1.rockspec

As you can see, the .rockspec still points to Github, altough I have in addition made an src-package in rocks.moonscript.org.

But this is not as neatly integrated with OpenResty. Luarocks doesn't nicely handle for example external dependencies to FFI bound C-libs. Right now I just supply .lua-files in Luarocks. But many of the libs I have made are actually luafied wrappers to C-libs via LuaJIT's FFI. That leaves you with manual work (e.g. using your OS package manager, compiling those .sos/.dylibs/.dlls on your own and placing them on correct path where the OpenResty's LuaJIT can pick them up). I'm also not sure if the .lua files should be placed manually as well. Some of the code is OpenResty dependend (e.g. uses ngx.*) and some aren't. The Luarocks is a mess in that sense. You never know what the dependencies of a Luarocks packages are. Do you need LuaJIT (and what version), do you need to run the code in context of a OpenResty or maybe something else like Turbo.lua. Does the code depend on a framework like Lapis, can you get the dependend libs built on your OS, etc.

In that sense OpenResty is a lot like say Node.js. Node.js has its own package management called npm that is used to manage Node modules. But it could be used to manage client/browser js-modules as well (e.g. with browserify). Still, bower is an another option to be used in client side package management (a lot of client libs have deps to images and css files too).

I'm not sure how this mess is to be solved. Having a package manager solely for OpenResty would be one way to go. Still, does this tool need to manage say client-side/browser libs as well. Would you like to package your lua-resty-* package that has client side lib/css/imgs as well in a same package? Creating a yet another package manager for client libs. Or are you forced to run bower, operating system package manager, npm etc. side-by-side with OpenResty package manager.

It sure could be an option if there was a OpenResty tested or dependend repository. rocks.moonscript.org has something called manifests where you could place your lib in OpenResty manifest, but the concept of manifests is not defined.  There are manifests currently named as "tarantool", "lapis", "luajit" and "root". But no-one really knows what those mean. If I put package in root manifest does it mean something. What if I put it in root and luajit? And then there are version dependencies as well.

This is a really hard problem to solve. I think OpenResty needs something, npm equivalent of a thing. Where things just work. But it is easier to say than actually make it work. Do you want to enforce conventions? Do you want to integrate this package manager with other OS package managers, and maybe with LuaRocks, how do you manage the possible client side assets (a convention including nginx configuration to make them servable...)

Regards

Aapo

[Yichun Zhang (agentzh)]

Hello!

On Tue, Nov 4, 2014 at 6:21 AM, Aapo Talvensaari wrote:
> But this is not as neatly integrated with OpenResty. Luarocks doesn't nicely
> handle for example external dependencies to FFI bound C-libs.

Yes, I'm going to work on the luaresty command line utility for
package management in the OpenResty world. And I'd like to address
such issues in a clean and consistent way. Because "luaresty" does not
need to worry about non-OpenResty things, it could be much simplified.

And I'm going to run the site luaresty.org to host OpenResty libraries
as well as OpenResty applications.

The "luaresty" utility may fall back to moonrocks (or luarocks)
automatically if a package is not found on luaresty.org but on the
latter's.

> You
> never know what the dependencies of a Luarocks packages are.

For "luaresty", I'd like the author to explicitly specify the
dependencies. The luaresty.org site may run some automatic dep
detection and report any issues to the authors (or users).

> Node.js has its own
> package management called npm that is used to manage Node modules.

Yes, I'll have a closer look at npm and borrows whatever good ideas
fitting OpenResty's needs :)

> I'm not sure how this mess is to be solved. Having a package manager solely
> for OpenResty would be one way to go.

After much thinking, I'd go that route if nothing else pops up :)

I meant to reuse leafo's moonrocks work. But I find it hard to miss
the chance to design something so important from scratch ;) Oh well, I
must say leafo has made great contributions, especially to OpenResty
:)

Also, as you can tell, I'm also a heavy Perl user and I do have strong
opinions after using of its CPAN for years :)

> Still, does this tool need to manage
> say client-side/browser libs as well. Would you like to package your
> lua-resty-* package that has client side lib/css/imgs as well in a same
> package?

Yes, I'd see complete web applications distributed via luaresty :)

In addition, I'd also like the capability of automatically generating
binary packages via "luaresty.org" for popular package systems like
Debian and Yum.

> This is a really hard problem to solve. I think OpenResty needs something,
> npm equivalent of a thing. Where things just work.

I cannot agree more :)

> But it is easier to say
> than actually make it work. Do you want to enforce conventions?

Yes, I want to enforce conventions and consistency in a central place
like luaresty.org. That way we can have a lot of interesting tools
built around it.

> Do you want
> to integrate this package manager with other OS package managers, and maybe
> with LuaRocks,

Yes, but just one-way directions, that is, to OS package manager, and
from LuaRocks.

> how do you manage the possible client side assets (a
> convention including nginx configuration to make them servable...)
>

We'll eventually figure out with help from everyone, including you of course :)

I hope the design work around luaresty is open to the whole community.
You opinion matters, as always :)

Best regards,
-agentzh