Replies: 8 comments 10 replies
-
|
(thank you initiating this new place!) we've spoken about this in the past and there are certainly some tangled issues with trying to "solve" the dependency problem. my inclination:
this still relies on the script author to manage deps (which i think is not unreasonable) but hopefully sets a proper pattern to follow. i'm not inclined to weave in full dep-management magic. (side note: i'm confused why ugen management has to be so confusing, but this is likely better discussed as a separate issue) we've had many discussions regarding |
Beta Was this translation helpful? Give feedback.
-
|
the biggest dependency management hurdle I've encountered is definitely the ugen management. for scripts its not a big deal - scripts fail and people report and we can pretty easily say why it fails since lua/maiden gives some hint at what lua dependency failed. more importantly, when a script doesn't have a dependency it won't start, but it won't affect anything else. ugens are trickier. SuperCollider will fail to start if it detects two ugens of the same name. this is problematic because it essentially bricks the norns: instead of one script not working, it makes all scripts unable to work. as @sixolet mentioned I tried to develop a script in paracosms (which is using a couple 3rd party ugens) to detect ugens and not to copy them if they already exist. paracosms does this by storing its ugens in a (detecting an existing ugen is tricky because there are three main locations they can be in:
all of these are perfectly valid locations for putting 3rd-party ugen files, although the last one I think is considered the most canonical now.) A solution to this ugen thicket might be a universal script to manage all the 3rd-party ugens, something like the monome-community scripts (I started iterating on this idea). another solution might look like detecting a SuperCollider FAIL and in the case of a duplicated class report it or quarantine it to an "ignore" directory so it doesn't brick the norns. anyways, open to any ideas so there can be fewer items in this thread |
Beta Was this translation helpful? Give feedback.
-
|
I’m happy with dependency management being on script authors, with some library support. I would like to remove it as a consideration for script users. A method to test for the presence of a library is nice, but I think even better would be a script-side hook into the maiden |
Beta Was this translation helpful? Give feedback.
-
|
Couple of random comments that are hopefully helpful. There is API for detecting whether a given mod is available/loaded or not. https://github.com/monome/norns/blob/main/lua/core/mods.lua#L90-L92 but I don't remember what the state of documentation is around mods beyond the original example code. If scripts are relying on functionality in mods then it would be good to test for them as a best practice. Adding dependency management of some sort can certainly ease initial installation but without a whole bunch of additional work on the part of the script authors I'm not sure it would really help with maintaining stability over time. The more interconnected things get the more there is the possibility for script A and script B want different versions of a given dependency. Dependencies could be versioned with something like semver yet then it is entirely on the authors to know how to apply semver correctly. In order to avoid conflicts and interdependencies I would personally advocate the vendored approach (I personally use git submodules but I recognize those aren't for everyone). Vendored dependencies allow me to freely change library like code I've written without breaking older scripts that I want to retain but don't have time to update. One "dependency" not mentioned above that comes up frequently is which version of the norns software itself a given script assumes. There are plenty of examples where a new script is released, it doesn't work for someone, and the resolution is to have them update their device to the latest software. I see benefit in providing a function which could be placed at the top of a script which checks that the norns software is >= a given version like 20220310, if not fail gracefully with an on screen error. The |
Beta Was this translation helpful? Give feedback.
-
|
i'm very much in favor of of something like even if you haven't dug into the menu code before this should be a pretty straightforward PR if someone wants to get into it |
Beta Was this translation helpful? Give feedback.
-
|
could be extended to (i'd love to have a so basically as a phase one, we could skip over any programmatic dependency management and offload that to the user. |
Beta Was this translation helpful? Give feedback.
-
|
probably the version required should be an integer, since it will increase over time, so you can just implement the check with an inequality. I'll give this more basic thing a shot |
Beta Was this translation helpful? Give feedback.
-
|
we already have an "engine not found" mechanism makes sense that the version should be an integer for comparison |
Beta Was this translation helpful? Give feedback.
-
|
if it helps, this has been working for cheat codes 2. |
Beta Was this translation helpful? Give feedback.
-
|
I gave it a shot in #1613. It occurs to me that while @dndrks's idea is super rad, it's not really possible to implement on a system level as far as I can tell, since in order for norns to know that a new image was necessary, an update newer than the image needs to be on norns. Nevertheless, I included a suggestion about checking for a new disk image in the maiden output. |
Beta Was this translation helpful? Give feedback.
-
|
thank you! yes we frequently run into this issue--- we want an error alert for something but we can't retroactively add it to previous versions without having an update. i hit this wall dozens of times trying to refine the actual update process :) |
Beta Was this translation helpful? Give feedback.
-
|
Regarding UGens, here's a pattern that I shared on Discord that will allow a script to install a UGen shipped with the script in an -- script
local extensions = "/home/we/.local/share/SuperCollider/Extensions"
engine.name = util.file_exists(extensions .. "/UGenName/UGenName.sc") and "EngineName" or nil
UI = require("ui")
function init()
Needs_Restart = false
local ugen_files = {"UGenName.sc", "UGenName_scsynth.so"}
for _,file in pairs(ugen_files) do
if not util.file_exists(extensions .. "/UGenName/" .. file) then
util.os_capture("mkdir " .. extensions .. "UGenName")
util.os_capture("cp " .. norns.state.path .. "/ignore/" .. file .. " " .. extensions .. "/UGenName/" .. file)
print("installed " .. file)
Needs_Restart = true
end
end
Restart_Message = UI.Message.new{"please restart norns"}
if Needs_Restart then redraw() return end
-- rest of init()
end
function redraw()
if Needs_Restart then
screen.clear()
Restart_Message:redraw()
screen.update()
return
end
-- rest of redraw()
end |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @ryleelyman, I'm using this right now for a script and it worked great. while on the subject of compiled UGens - there was another "gotcha" I found when paracosms started being downloaded by people with fates. I was distributing compiled UGens and UGens I distributed were compiled on my norns shield. However it came to be a problem when people installed them on their "fates" because fates is currently behind in its GLIBC (2.28 since its Debian 10) so they would get errors. To fix the problem I asked okyeron to recompile everything on their fates, and then I distributed those instead (since GLIBC is backwards compatible this works with the newer GLIBC on norns). Its not a very sustainable solution...since I don't have a fates or a 32-bit Debian 10 system I can't really re-compile anything if anything changes. Another possibility to circumvent this particular fates vs norns problem is to compile the UGen as part of the process of installing (which is what I'm doing with fverb in zxcvbn now). The above script enabled that for me (each user compiles the fverb code on their own norns, whatever version it is). |
Beta Was this translation helpful? Give feedback.
-
|
hmmmm. that's quite a gotcha. the UGens I made need does this mean that the scripts that use my UGens will fail on fates? if so, I'm kind of surprised nobody with one has tried bitters, lamination or schicksalslied 😅 |
Beta Was this translation helpful? Give feedback.
-
|
no not necessarily! for all I know it only happened with a particular UGen from f0plugins on fates (i.e. here). but I can't say I know much about this - I don't understand either fates or SuperCollider compilation entirely. I know that this didn't happen with other plugins (like |
Beta Was this translation helpful? Give feedback.
-
|
i'd be up for considering a core component (ie, included in the main norns codebase) which is an install helper. this way a script could achieve the above simply by requiring an engine lib ie require Polysub, which would in turn do a norns.require.ugen (or something) which could check for the ugen and if needed install it from the local folder and issue a restart request, or if not found sound an alarm we may need to have a correlate on-startup check to debug/fix/alert the user of misplaced ugens--- though this is a broader issue when it comes to .sc files (class collision, which is harder to solve) |
Beta Was this translation helpful? Give feedback.
-
|
I'll give this first piece a shot. maybe an |
Beta Was this translation helpful? Give feedback.
-
|
gave it a try in #1614. Managed to create a persistent |
Beta Was this translation helpful? Give feedback.
-
I'm interested in how we can manage dependencies for Norns scripts, in a way that isn't a heavy burden for script authors, and is mostly transparent for script users.
Uhh "user journeys" or something
Some use cases I am imagining, along with their current "solutions":
toolkitmod errors if thematrixmod is not installed, and is pointless if thematrixmod is not active. I would like to installmatrix(if it's not installed) when installingtoolkit.Thoughts toward solutions
;installoperation should automatically install the dependencies.Challenges
libraryorstable apitag to Maiden projects to indicate ones where the author commits to keeping thelibAPIs backwards compatible. This requires library authors to be very good at backwards compatibility, though. And people will still depend on unstable stuff.Not this project
Rocks. Unfortunately, I don't think they are all that suited to projects that are naturally often a mix of lua and sc.Beta Was this translation helpful? Give feedback.
All reactions