2022-12-26 - my fennel cursed url loader

Hace tiempo vengo ahí tentándome con hacer un url loader en fennel. La cuestión es que lua te permite crear tus propias estrategias para cargar librerías/módulos.
Esto lo logras aprovechando package.searchers, que es una lista de funciones que se ejecuta una a la vez hasta que alguna devuelva algo. Así podés tener un programita que resuelva la búsqueda del módulo al cual haces require.
Usando curl y uuidgen (dos programitas que suelen estar en linux) arme un peque módulo en fnl que me permite hacer algo como:

(local a (require "https://git.sr.ht/~szgy/fnlbundle/blob/main/anis.fnl"))

Cuando un programa que tenga cargado mi url-loader en los package.searchers vea algo así, va a checkear en $LUA_CACHE/.import-map. $LUA_CACHE es una variable de entorno que me inventé y que hoy la ubiqué en $HOME/.lua/cache.
.import-map es un archivo fennel con un objeto tipo:

{url uuid
url2 uuid2}

si la url que se require no existe en ese objeto, se hace un request usando curl y se genera un uuid usando uuidgen, se cargan en ese mapa y se descarga el archivo a $LUA_CACHE. De esa manera, la próxima vez que se haga require, no hace falta pedir el archivo de vuelta.
Todavía no publiqué nada de esto, pero pienso que puede estar diver para manejar así mis dotfiles de neovim.
A la vez, pienso que es un buen primer paso para explorar un gestor de paquetes medio mínimal que use la red de bit-torrent y la posibilidad de usar torrents mutables para tener una solución p2p.
En ese caso el sistema tendría que ser un toque más sofisticado.
No podría usar urls directamente ya que los magnet links son medio un garrón para andar metiéndolos en el código. Pero si podría usar el import map para hacer algo del estilo de:

{:szgy {:anis "magnet link"
        :other-lib "other magnet link"}}
;; y después cuando quiera usar algo
(local a (require :szgy/anis))

Siempre el problema con ambas cuestiones (url load o gestor de paquetes distribuidos) está en que si cargo un archivo con ese método y ese archivo hace require también, la estrategia de cargado tiene que estar contemplada por el usuario de la librería. Esto implica una suerte de acuerdo tácito que todavía no se bien cuán incómodo sería.
En fin, más allá de todo, me divierte pensar en estas giladas...
Por otro lado, me hubiese gustado embeber el código de la librería usando custom components y tonic.js, pero sr.ht pages no me deja hacer un request a un archivo que no esté en el mismo dominio que donde se hostea la página, lo cual respeto pero alta pajurri.