I’ve been thinking about the best way to share a SilverBullet library - something like Library/Std but more custom. Since I recently had time to port a few scripts from v1 to v2, I figured: why not hack together a half-decent distribution setup?
Gist imports are neat and minimal, but let’s be honest - they’re not great for anything you plan to maintain. GitHub, on the other hand, brings in the big guns: issues, PRs, branches…
So, I cobbled together a prototype setup. It’s a bit of a Rube Goldberg machine, but it works surprisingly well.
Here’s the idea, step by step:
Start importing the stripped-down version of Library/Silver (yeah, I called the library Silver, sue me )
Click the reload button
Smash that upgrade button like it’s 1999
Boom: it fetches the full Library/Silver page straight from GitHub
Rinse and repeat: reload → upgrade
Now you’ve got all the modules under Library/Silver/*
One final reload, and like magic, everything’s wired up
Once everything is done, the library can be updated easily. Just upgrade → reload
If you’re brave (or bored), feel free to try it out: Silver.md · GitHub
But fair warning: the actual library isn’t the star of the show here - it’s the distribution workflow I’m experimenting with.
Would love to hear if any of you have better setups, or weirder ones.
First, I think it’s very nice that you are experimenting with this and cool that it’s actually possible to do so. Pats himself on the back
On your specific solution. Let me reformulate what I reverse engineered from your code to check that I understand it.
You configure this by setting silver.path and silver.repo. Only one repo is supported (for now, or by design?)
In this Github repo, you keep markdown files under contents/Silver tagged with #lib/silver.
Others (or yourself), can then configure that same repo in their space, and through Silver: Upgrade fetch updates for those files. But not new ones, right, because those wouldn’t be detected?
Now my questions are:
You support one repo, is that a choice or do you have a way in mind to support multiple? If it’s just one, then it can really only be used in a centralized way, meaning: a big giant SilverBullet library where everybody pushes their library code. This may be ok, but it would be nicer to support multiple to avoid bottlenecks.
How to pull in new library code? Right now it only updates existing ones.
This approach was initially just to solve my own need: distributing my library across multiple SilverBullet instances I run. I wanted a clean way to sync a GitHub-maintained library across them all.¹
Extending this to support a list of repositories would be trivial.² But the main point of this post/experiment is to figure out how to fetch/distribute a library in the first place. Once that feels solid, I’d love to harden the approach and make it more bullet-proof.
That’s handled via the silver.modules list defined in Silver.md. It lists all available modules in the library. The user can override it to load just a subset if they prefer. These modules are fetched and updated - even if they don’t already exist in the Space. So no need for manual stubs or pre-creating files.
¹ Ideally this wouldn’t depend on the GitHub API, but I haven’t found a good way to do this cleanly with just git (and support self-hosted repos).
² Currently, the library contains both the actual library modules (Silver/*.md) and the distribution mechanism (Silver.md). If this ever becomes something more widely adopted, I think it’d make sense for the distribution mechanism to move into SilverBullet itself - so the interface is consistent for all libraries out there.
)