Introduce NodeMCU Lua module directory

[marcelstoer]

Reviewing, hosting and thus potentially maintaining an ever growing pile of NodeMCU Lua modules doesn't scale well.

Instead we should add a GitHub wiki page that lists NodeMCU Lua modules by various authors and link to the external source. Wiki pages are open to anyone for editing. We would state clearly that a module being listed there doesn't mean we endorse it in any way.

Furthermore, we can add a new page to our documentation that points to the wiki page.

In the (hopefully not too distant) future, we will request that Lua modules to be hosted in this repository come with a test program in whatever framework we end up adopting.

[marcelstoer]

Done: https://github.com/nodemcu/nodemcu-firmware/wiki/Lua-modules-directory

[HHHartmann]

Is this really done?

Above we mention

Furthermore, we can add a new page to our documentation that points to the wiki page.

And after all it's "do good and talk about it"

[TerryE]

@marcelstoer, I also think that it is a little premature to close your issue. @jpeletier introduced a parallel and albeit ESP32-specific issue covering a similar topic #3100. If we are ever going to unify the code base across both variants, I feel that we should:

• define a split between the core components and modules which are those where where is some level of commitment from the project committers to maintain this set and to ensure a level of operability across any SDK, Lua engine and NodeMCU modules.
• Have a means of maintaining a knowledge base of non-core modules where it is up to the originator to maintain the component.

We might also have a parallel a knowledge base of non-core documentation and FAQ points.

As Javier suggests we should also investigate some standardised method for developers to assemble such components with the core build with some degree of assembly automation. Using github sub-project for such add-in where each sub-project has a very standard structure and some form of standard metadata using YAML or whatever, with a builder script that automates assembly seems the way to go, but we should all discuss this further.

[jpeletier]

[...] parallel and albeit ESP32-specific issue

In #3100 you have a working implementation for ESP32. If it is accepted, my idea is to create the same for ESP8266, but sharing the code among the two branches via a submodule, to have the same system for both branches.

This will also open the possiblity to write external C modules that work for both ESP32 and ESP8266.

define a split between the core components and modules [...]

In #3100 I suggest the following policy to deal with modules:

1. Modules that expose internal hardware. In essence, anything anyone can test with the typical dev board and a few LEDs: KEEP AS-IS.
2. Software modules that everyone needs, such as mqtt, http, etc: KEEP AS-IS
3. Existing modules within the tree that drive very common external hardware such as an SD card or a typical i2c device, etc: move to EXTERNAL at some point, but within the nodemcu GitHub org.
4. Newly created modules that drive any other hardware: EXTERNAL, in the module owner's repo. Here are some example PRs that would then be closed and become external modules: ESP32: Sonar Module #3090, ESP32: TRIAC phase-dimming module #3023, ESP32 add sdm module #2767, ESP8266 add sdm module #2766, Add support for BH1750FVI ambient light sensors #2261, Added support for custom rfswitch protocol definition (id = 0) #2255, Add support for HTU21D/SHT21 temperature and humidity sensors (ESP32) #2250, Add support for HTU21D/SHT21 temperature and humidity sensors #2249.
5. Newly created software-only modules that implement some application-specific protocol, modules that offload Lua for a specific application, modules that implement proprietary algorithms/communication protocols, etc: EXTERNAL.
6. Closed-source code for company projects, etc: EXTERNAL, potentially will be in a private repository.

[...] Have a means of maintaining a knowledge base of non-core modules where it is up to the originator to maintain the component.

After #3100 is merged I intend to create a registry git repository where people can PR to submit a link to their modules. If we see the module is properly documented and has a reasonable degree of documentation, we accept the PR, thus listing the module automatically.

As Javier suggests we should also investigate some standardised method for developers to assemble such components with the core build with some degree of assembly automation.

The working implementation in #3100 allows you to do this by editing a text file. The next step would be to have it connect to the registry mentioned above so that it becomes aware of modules that can be pulled into the build (like what you do with make menuconfig when selecting what modules to include)

[...] each sub-project has a very standard structure and some form of standard metadata using YAML or whatever, with a builder script that automates assembly seems the way to go, but we should all discuss this further

Please take a look at my hello world external module example for a first version of this. As of now, you can have an optional module.mk (behaves like a component.mk) if you need to build your module in a special way, but for most modules it is not necessary.

[marcelstoer]

@TerryE @jpeletier can we please not mix the Lua registry and C registry discussions? The two are definitely related but the requirements & constraints are different. Copying in comments from #3100 isn't helpful IMO. I will give my feedback there.