Esper
What is it?
Esper is a super lossy packaging system.
What I mean by that is that Esper mimics some of the features that are typical to a packaging system, and ignores others. It's meant to provide an easy template system to consolidate acquisition, creation, and installation of resources, but offers no version controlling or dependency checks. At least for the time being that is. What all of this means is that Esper is excellent for non-reproducible, localized installations. Such as what you'd find on a shared server instance like a tilde server, or for internal tooling for a small team, or even inside of dockerized build systems.
Most packaging systems utilize a simple flat configuration file to define their packages. You'll find pkgname=something, and build(){ make all } calls are ubiquitous, and Esper is very much the same. Since Esper is written in Fennel we stick to the basics and use Lua tables for our configuration. This design keeps it relatively simple and familiar, not too far diverged from what package maintainers might expect, but even more so, in one of the simplest data structures in one of the easiest to acquire languages that exists.
That said, here are a couple of examples. Firstly an esperbuild for Fennel:
{
fetch={url="https://git.sr.ht/~technomancy/fennel/archive/0.6.0.tar.gz",
git=false,
outf="fennel-0.6.0.tar.gz",
extract=true,
atype="gzip"},
builddir="/Fennel-0.6.0",
depends={
alpine="lua5.3 lua5.3-dev lua5.3-libs gcc make",
debian="lua5.3 liblua5.3 liblua5.3-dev gcc make"
},
build={"make fennel-bin"},
rename={
{old="fennel", new="fennel-lua"},
{old="fennel-bin", new="fennel"}
},
inst={
{perms=755, {"fennel"}, out="/usr/local/bin/"}
}
}
And another for epr, a CLI book reader written in python.
{
fetch={url="https://github.com/wustho/epr.git",
git=true,
outf=""},
builddir="/epr",
build={},
rename={{old="epr.py", new="epr"}},
inst={
{perms=755, {"epr"}, out="~/Scripts/"}
}
}
The README on the Gitlab page has a break down of each symbols value, with use cases and examples. But at a mile high view, each esper describes a fetch method, a build directory, build function, and installation directive. Additionally we can play with the output a little, renaming things before they're installed, or sourcing files from tarballs, the local file system, or git repos. In some small way, I feel like Esper takes a bit of inspiration from VOID templates, which try to provide easy function handlers for installation, and my own experiences trying to learn how to deal with Alpine and Arch packages. Esper is hopefully simple enough to allow someone to consistently install random utilities not provided by their distro to a custom Scripts directory in their $PATH, but also complex enough to distribute in house tooling.
Expectations:
Honestly I expect very few people to actually use this, it was an interesting way for me to learn what it might take to build a small packaging system, and it works for its limited scope rather well. As I use it, and eventually deploy it to tilde.town for general consumption, I hope that I can build in more complexity, such as dependency handling. In a lot of ways I feel like the structure is fragile. Depending on external programs via (os.execute)/(io.popen) rather than internal libraries or CFFI. Using something like (os.execute (.. "wget " url)) should probably be handled with luasocket or cURL, with fennel's --require-as-include it's extremely trivial to include lua source, but even library dependencies inside of the compiled binary, with minimal effort.
All of that to say I'll probably revisit this project on and off and rewrite major portions of it while attempting to preserve functionality, all with the hopes that an official package for the esper system won't do silly things like have a depends="wget git ..." inside of it, when at least some of that can be handled well enough by itself.
Contact
If you'd like to contact me about my software, ponderings, or just to chat; you can reach me at wpsinatra@gmail.com