As I’m developing more tools I’m faced with the annoyance of having to duplicate the same helper functions inside the scripts of different tools. Has anyone tackled this problem before?
Thought about having a “base tool” that would contain common scripts my other tools could include in their source. Of course this could lead to issues across different versions and such but nevertheless here is a function that does the inclusion. It also makes it possible to rely on any other tool in general but that is even dirtier
function include(dir, module)
local path = dir .. "/" .. module .. ".lua"
local file = io.open(path, "rb")
if(file ~= nil) then
package.path = package.path .. ";".. dir .. "/?.lua"
-- should only append the dir if its not in the path already but oh well
require(module)
else
local message = path .. " not found!\n make sure you have " .. dir .. " installed!"
renoise.app():show_prompt("missing dependecy!", message, {"OK"})
end
end
And one would use it similarly to require like:
include("../com.exampler.base_tool.xrnx", "util")
to include a script named util.lua from another installed tool.
To be clear, not saying this is a good solution or that anyone should use this, just sharing for fun.
I guess another way might be to pack all my tools into a single tool as they don’t take up much space anyways and they only offer keybindings so there is little drawback to having all of them installed.
Alternatively one could “build” tools by including the necessary files but I like the fact that my source is the same thing as the distributed tool.
Cool, looks like I went through a similar thought-process 4 years later haha. My snippet is pretty much the same thing you explained with added checking and warning if the required file doesn’t exists.
The problem with your last suggestion of having a standard library of some sorts is that then every time I’d write a function to be reused it would need to be accepted and included by the maintainer of this library for me to be able to actually use it.
Another thing that a tool could be doing is updating its own common code by pulling it from a repository if needed, but that is basically duplicating functionality of the already existing tool updater.
Maybe it isn’t too bad to “force” people to install some kind of “base tool” to be able to use another. As long as you don’t rely on other people’s tools it should be easy to maintain stability.
No, in that case one would take the Ruby gem approach.
Interestingly, more and more of the Ruby standard library is moving toward gems as a way to avoid this monolithic central repo of shared code. This allows for individual libraries to be updated independent of a formal Ruby version release. Currently, a release of Ruby includes a set of “standard gems”, which can then be updated individually over time as needed.
I would prefer this approach, a way for Renoise to install user-written libs that other tools could use. As it is, you can do this by installing a “tool” that is simply library code, and other tools can references it by knowing the relative path.
What’s missing now from Renoise is a way for the tool installation process to fetch and install tool dependencies if they are not already installed, or if a specific version is specified.
My current tool development process does use a script to copy over a set of utility files when I create a new tool project so that I need only maintain them in one place.
Anyway, I started exploring the shared code thing a proof-of-concept because, like you, I think it goofy to have to replicate basic stuff everywhere.
I didn’t bother with error handling and messages for missing files because if it failed I’d know right away from the dev console and fix it (since this was just for me).
I’d have to look and see if any of the tools I use myself but have never released use that approach.
