|
My question is: Am I asking for trouble by taking this approach? Apologies for the long post. I did not have enough time to write a shorter one. ;-) Rosie[1] is an application which exposes a CLI and a C API. The C API, librosie, can be used from languages like Python, node.js, Ruby, Go, and others[2]. But what about Lua users? Rosie is written in Lua, so I wrote a proper Lua module in a file called 'rosie.lua' . (The 'rosie.lua' file is created from a template when you install Rosie[3] and build the development branch, tranche-2, because it contains an explicit reference to the Rosie install directory.) The 'rosie.lua' file can be copied to wherever the user keeps their Lua module files, such as /usr/local/lib/lua/5.3, and it will look in the Rosie installation directory for everything needed to run Rosie. Thus a single installation of Rosie on a machine will be usable by CLI users, Lua developers, Python developers, etc. Because Rosie uses C libraries like lpeg.so, 'rosie.lua' loads them from the Rosie installation directory, to ensure that exactly the supported versions are loaded[4]. This also simplifies things for the Lua user, who does not need to install those C libraries in their Lua environment, or who may have different versions of those libraries already installed. The loading of Lua and C modules is done by a quick hack of a "private module system" that I wrote in an hour. It's literally around 40 lines of code[5] (yay, Lua!). This quick hack does two things: (1) it loads code from the right place, and (2) it hides all the Rosie internals from the Lua user, including the fact that some C libraries were loaded. When you type 'r = require "rosie"', you get exactly one new global, 'r'. If you look in 'package.loaded', you will see only one new entry (for rosie). When the user does 'lpeg = require "lpeg"', their own version of lpeg.so is loaded (from wherever they installed it) and everything appears to work fine. Rosie has its "private" lpeg, and the user has their own. Is this situation problematic? In what situations will it cause trouble for users? The usual alternative is to make the user install the various C libraries needed by Rosie into their usual Lua lib directory, and for 'rosie.lua' to load them from there. But this can cause "dependency hell", if the user's needs and Rosie's needs diverge, right? Thanks, Jamie [1] Rosie is at https://github.com/jamiejennings/rosie-pattern-language [2] Crude sample programs and modules are provided. See, e.g. rosie.py at https://github.com/jamiejennings/rosie-pattern-language/blob/master/ffi/samples/python/rosie.py [3] The addition of 'rosie.lua' is not yet in a proper release. It is in the development branch https://github.com/jamiejennings/rosie-pattern-language/tree/tranche-2 and is created when Rosie is built. [4] rosie.lua loads init.lua which contains this line: loadfile(ROSIE_HOME .. "/src/core/load-modules.lua", "t", _ENV) [5] Private module hack is https://github.com/jamiejennings/rosie-pattern-language/blob/tranche-2/src/core/load-modules.lua#L32-L72 |