lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


There have been a lot of attempts to solve that issue in the past.

The "blessed subset of libraries" never worked for many reasons.

Kepler Project worked for a while, but died for lack of funding.

At some point I created Lua Toolbox [1] to at least have some kind
of ranking of the most used gems in the community. The main feature
was the ability to explicitly endorse some rocks, so that you could
find out the most endorsed rock for a given category. It was kind of
merged into LuaRocks but I feel like it isn't really usable anymore.

There was also a plan to create a Lua Foundation to deal with those
issues, but it went nowhere...

Eventually I think what proved to work best so far is the Lua
distributions approach, where someone curates a list of libraries
and maintains a coherent whole, separate from upstream projects
like Linux distributions do.

[1] https://lua-toolbox.com

-- 
Pierre Chapuis


On Mon, Jan 20, 2020, at 10:41, Rodrigo Azevedo wrote:
Motivated by recent discussions about standard libraries and codes, I have the following considerations:

The main problem to be addressed is not a set of 'blessed' libraries by Lua Team, but instead one repository of codes that the COMMUNITY TRUST, USE, IMPROVE and HELP to increase.  It means, when someone on this list asks about a library, everybody must agree on a first default answer. Public libraries are blessed by the community, not a specific restricted set of people.

Reasoning. Lua community, at least on this list, is obviously well versed in programming/IT/CS which naturally leads to "I can write my 'best' library myself that do what I want in my way", and that's exactly the main problem. We can do it, but public libraries are useful exactly for ones that can't or don't want to write their own 'best' whatever. The ego of 'I can do it better' must be superimposed by 'it is enough for most of them'. "THEM", not "me".

Then, I propose the following project:

LuaDEAL - Lua DEad Alive Libraries
Lua Modules

They're not aimed to be "the best," most powerful codes, but something useful enough for someone doesn't need to reimplement the wheel again. They must have a well defined and stable "Lua-ish" API. Documentation is mandatory.

A) Composed mainly of categories:
  Tomb1 - Lua-only libraries and codes
  Tomb2 - Wrapper from well-established C libraries.
  Tomb3 - Lua-only C libraries


B) The design must follow the philosophy of minimalist, modular software:
  0) Open, community-based, development. MIT license whenever possible.
  1) Lua's "mechanisms instead of policies," whenever possible.
  2) They must do only one thing and do it well. The aim is to do a trivial job.
  3) They must be as independent as possible but work very well together.
  If you are wondering about examples, think about Lua itself and its standard library as well as lhf libraries.

C) Code Standards
   1) Follow semantic versioning.
   2) No use of globals, never, anywhere.
   3) Standard headers for different modules.
   3.1) Name of the module
   3.2) Date of module creation
   3.3) Author of the module
   3.4) Modification history
   3.5) Synopsis of the module about what the module does
   3.6) Different functions supported in the module along with their input-output parameters
   4) Exported API must follow the existing Lua names and design conventions.
   5) Must work flawlessly on recent versions of Linux/Mac/Windows if the underlying necessary libraries are present.

If only a subset of the readers of the list really commits to public libraries, it means, codes for other ones use, I'm sure that a set of standard modules could be available for the community still this year. It obviously will require the rework os many wheels, fortunately to they R.I.P. on the repository for a long time. Public libraries are an exercise of detachment.

Best,
Rodrigo