Package lime-utils independently from lime-system

[ilario]

I copy and paste here the original discussion started on #766:

@spiccinini

Some packages depend only in the lime.utils part of lime-system package. In my opinion we should refactor out this lua module into its own package.

@ilario

Some packages depend only in the lime.utils part of lime-system package. In my opinion we should refactor out this lua module into its own package.

To add some data, here you are a table of the required lua files from lime-system by each package:

Package	Required lua file
deferable-reboot	lime.config lime.utils
first-boot-wizard	lime.config lime.utils lime.wireless
lime-hwd-ground-routing	lime.config lime.hardware_detection lime.utils
lime-hwd-openwrt-wan	lime.config lime.hardware_detection lime.network lime.hwd.openwrt_wan lime.utils
lime-hwd-usbradio	lime.config lime.hardware_detection lime.utils
lime-proto-anygw	lime.config lime.network lime.system
lime-proto-babeld	lime.config lime.network
lime-proto-batadv	lime.config lime.network lime.proto lime.utils lime.wireless
lime-proto-bgp	lime.config lime.network lime.utils
lime-proto-bmx6	lime.config lime.network lime.utils lime.wireless
lime-proto-bmx7	lime.config lime.network lime.utils lime.wireless
lime-proto-olsr	lime.config lime.network lime.utils lime.wireless
lime-proto-olsr2	lime.config lime.network lime.utils lime.wireless
lime-proto-olsr6	lime.config ime.network lime.utils lime.wireless
lime-proto-wan	lime.utils
lime-smart-wifi	lime.config lime.utils lime.wireless
lime-system	lime.config lime.generic_config lime.mode lime.network lime.system lime.utils lime.wireless
lime-webui	lime.config
safe-upgrade	lime.utils
shared-state	lime.utils lime.wireless
ubus-lime-batman-adv	lime.utils
ubus-lime-bmx6	lime.utils
ubus-lime-groundrouting	lime.config lime.network
ubus-lime-location	lime.config lime.network lime.utils lime.wireless
ubus-lime-metrics	lime.utils
ubus-lime-openairview	lime.utils
ubus-lime-utils	lime.config lime.wireless lime.utils
wifi-unstuck-wa	lime.config lime.utils

There are 6 packages depending only from lime-system, still I do not agree with @spiccinini: to me it seems that all of these 6 packages are LibreMesh-specific ones, that make little sense in an installation without lime-system. Do you agree?

Another interesting, but unrelated, info that can be obtained from the table is that shared-state should also depend on lime-system, and that if we want to push it upstream we will have to change this.

Some packages depend only in the lime.utils part of lime-system package. In my opinion we should refactor out this lua module into its own package.

@ilario

Maybe I misunderstood @spiccinini proposal: are you proposing to make lime.utils a non-LibreMesh-related package which could end up in OpenWrt repositories?
In order to do this we should remove the usage of lime.config inside lime.utils.

@spiccinini

Maybe I misunderstood @spiccinini proposal: are you proposing to make lime.utils a non-LibreMesh-related package which could end up in OpenWrt repositories?
In order to do this we should remove the usage of lime.config inside lime.utils.

Yes, I think that it would be good to have part of the functionality that does not depend on the "lime" concept. And you are right about lime.config that it is in the middle. Some part of the fuctionality of lime.config is very handy outside libremesh too (the part that allows to make unittests with configs for example).
I know that at least in LuCi they are moving to javascript. I don't know about other openwrt related projects. Anyway in my opinion the only sane scripting language for openwrt remains to be lua. I don't know how valuable is for other projects to do this spliting.

[ilario]

utils.lua requires config.lua and modules.lua, so the easiest option would be to move them all together to a separated package, like the lime-utils that is being introduced here: #1276

[ilario]

Some of the functions in those packages are useful only for LibreMesh, while many others could be useful for other projects using OpenWrt. So a future project could be to separate these two categories of functions and push to OpenWrt's repositories the ones useful for them. Or just propose the whole thing and see what they think of this.