I’m a Mac sysadmin as part of my paid work, and have become used to creating installer packages to install software, admin scripts etc.
macOS installer packages can contain files (to be installed into specified directories), but can also run scripts to eg set options on device on which the package is being installed. Scripts can run before and/or after files have been merged into the target filesystem.
Is there an equivalent mechanism in the Norns ecosystem, whereby pre and/or post-install scripts can be run when a Norns script is installed?
Norns scripts arrive via git straight from a repo’s main branch, and are updated that way too. norns runs on Raspbian which has apt. The audio engine SuperCollider has Quarks as packages.
The norns scripts I’ve seen do post-installation operations do them my doing checks on launch, and making OS calls if necessary to install packages etc.
If git has post-clone hooks, they would serve a purpose maybe?
Thank you, that’s very useful. So I guess I’ll check for installed files etc. in my main Lua script, and pull them down via git or move them into place from the main script directory if necessary.
The general expectation/assumption is that “scripts” are just that, lua code which can be run immediately by simply cloning a git repo or unpacking a zip file. The unit of management is a directory in the code folder.
It is worth noting that scripts managed via git can use git submodules to pull in other dependencies as part of the install.
There is nothing that prevents a script from installing additional packages or “doing things” on first run but that is also not something which is necessarily encouraged. A script which installs packages and makes changes outside of the script directory is doing things which the end user cannot easily reverse or cleanup if they are no longer interested in the script. There have been occasions where scripts have installed packages which consumed a significant amount of space on the device. This can be problem, particularly for people with a factory norns running a CM3, those devices have 4GB storage total with 1.5-1.8G consumed by the base software.
while i’d discourage automated additional install components (those difficult to undo, specifically), i think it’s fine to list additional installation steps in your documentation, so that the person installing is very aware of the added footprint of the script. it also could facilitate more understanding: ie, if you encourage shelling in to execute commands. please include removal instructions as well.
lastly, if you have a script that has an external dependency, it’d be good to have that script be able to check for an unmet dependency and fail gracefully with an appropriate error message, to lower the support load (and direct it appropriately, instead of inducing panic that their machine is broken)
Thank you for adding this - I had intended to follow up with examples of where scripts have external dependencies and have surfaced the details in the documentation.
The point about checking dependencies and gracefully failing was another detail I wanted to highlight. While people might discover a script via its documentation here in a thread or on a norns.community page, someone might also install a script directly via maiden without looking at any associated documentation ahead of running the script.
i spent a lil’ time this morning thinkin’ about this and came up with this proposal for an example pattern:
during development of script comes_with_presets, i built a bunch of PSETs which ended up in my local dust/data/comes_with_presets folder
now that i want to distribute my script + presets, i created a bundled_psets folder inside of dust/code/comes_with_presets and dropped all of my generated dust/data/comes_with_presets files into it
assuming my PSET files increment linearly from 01, i can drop this into the init() function of comes_with_presets:
i’m sure there are ways to support scanning for non-linearly incrementing bundled PSET files, but it seemed fine to assume the default pattern should be "hey, you loaded the script and you don’t have any PSETs yet, so we gave you a few starting points in PARAMETERS > PSET slots 01 through 07"
anyway, just a starting point, but seems to work! excited to learn more about the needs to add something canonical to the docs!
