with more people coming on board, there is more demand and discussion around adding common utility functions.
penlight is maybe the closest thing to a lua standard library and has many functions for manipulating strings, tables, paths, sequences, classes, &c &c.
we already indirectly use it for development as a dependency of ldoc (same author i think.)
so should we maybe add add penlight to an update script?luarocks install penlight
pros:
cons:
+1 from me - there is some essential stuff in here that would be really nice to have by default. You will end up with bits of this functionality cut and pasted in anyway without it. As was pointed out in the forum - things like Python come with all this stuff anyway. Although list comprehensions using executable strings - ugh - that's just asking for trouble. whatever possessed them...
well, that speaks to my reservations. like many things in penlight, list comprehensions ultimately work by using loadstring, invoking the lua parser and code generator. not good for, say, a timer callback... (updated "cons" above)
updates should be executable offline, so it's better not to use luarocks, but rather ship the lib in the update tarball and install it somewhere in the search path.
Echoing what @junklight says, we either have homegrown versions of it, with homegrown bugs and worse documentation, or use an existing library.
It will increase the learning curve, but if the documentation is included then the discoverability will be high, and that in itself can help new programmers (i.e. why is there a copy and a deepcopy function... reads documentation / Google).
On a more abstract note, if we're looking at generally introducing people to coding then using libraries and standard libraries is part and parcel of it, and is a really good transferable skill (unless we're planning on going full SICP and starting from scratch).
The Penlight README.md has docs on installing manually. Also Debian has packages for lua-penlight (and lua-ldoc) if you want to stop using luarocks. You could include the deb in the update and install with dpkg (don't forget any dependencies too).
(If you do install lua-ldoc with dpkg you'll need to remove the existing version first!)
updates should be executable offline,
馃憤
so it's better not to use luarocks
actually, it looks like there are a few options for offline use. according to folks on stackoverflow, you can install local rocks or alternatively you can setup a local luarocks server.
FWIW, i'm keen to see a solution here too. adding the penlight library would be great for everyone. having a story for lua libraries would also help pave the way to new and exciting norns features that could leverage existing work. (as one example, see scry, the simple lua language server i've been playing around with).
i'm starting to feel less imperative that updates should be executed offline: if we need to get a file from the internet, put it on a USB stick, then insert it?
if we can make wifi connection reliable soon (fix timesync crash) i'd be up for reconsidering the update method entirely.
i see less of an issue using luarocks and am generally very much in favor of including something like penlight to reduce the amount of re-invention while coding
I鈥檓 wondering if to reduce complexity it would be friendlier to keep handpicking utility code to add to the Norns library, like the kind of functional utilities we see in fnutils/underscore.
As a script author I can always download a script on my dev machine (via luarocks or github, etc) and put it in my own script鈥檚 lib folder.
The only ugly part of this approach is if tons of third party scripts all use, eg, json and all have their own different copies in lib. I have not seen this yet though.
Most helpful comment
I鈥檓 wondering if to reduce complexity it would be friendlier to keep handpicking utility code to add to the Norns library, like the kind of functional utilities we see in fnutils/underscore.
As a script author I can always download a script on my dev machine (via luarocks or github, etc) and put it in my own script鈥檚 lib folder.
The only ugly part of this approach is if tons of third party scripts all use, eg, json and all have their own different copies in lib. I have not seen this yet though.