Thus far the docker edition of SilverBullet is relatively bare-bones, it’s a Debian based image with Deno. At some point I also added git and an ssh-client to it (I needed that).
Yesterday I was experimenting with Pandoc which is a pretty nice CLI program to turn markdown documents into e.g. epubs, PDFs etc. Generating PDFs from your notes has been a requested feature for some time, and simply leveraging pandoc can make this very easy to implement.
My initial prototype implementation is literally this:
```space-lua
command.define {
name = "Pandoc: Produce",
run = function()
local target = editor.prompt("File name")
shell.run("pandoc", {"-o", target, editor.getCurrentPage() .. ".md"})
editor.flashNotification "Done!"
end
}
```
However, this begs the question: how “fat” should we make the docker image? To make this work in my main environment, I’d now have to include pandoc as well as texlive (for PDF generation) in the image as well, this adds perhaps 50MB or perhaps even 100MB (not easy to tell) to the docker image. Is that a problem? Is there a better way to manage this?
One alternative option is that you simply check if the tool is available every time, and apt install it on the if not. Perhaps that’d be better?
If it is only a matter of installing Pandoc, when it is not already installed, then it seems to me it is a very simple thing to do. Why package it with SilverBullet?
Yeah, even writing this down made the solution kind of obvious. The only annoying thing is that this would result in a lot of (re)installations, since the installed software won’t persist between SB versions. Since I’m on the edge builds and sometimes I merge stuff daily, that means every day all this stuff would have to redownload.
kind of off-topic:
If you convert pages with pandoc, do you use “raw” md content only? What about the results of queries or LUA outputs, etc. ?
At first I had in mind the publish PLUG, which exports a whole page to a complete md file.
Is something like that possible, too with your LUA command from above?
That would be even better (or at least simpler for me) for some of my current ideas:
) like publish some pages to webspace without using the PLUG (as in my first experiments it lacks a few features, like adding pictures to the export).
Another idea is just like your pandoc example, but I’m experimenting with generating Presentations with “Marp”.
Ah, yes, you are right. In that case, I don’t know, I have my SilverBullet space available on my pc and pandoc is already there, so it is just a terminal command away to generate pdf from md.
There are ways to render the page to “clean” markdown. Have to check how to easily use this functionality. It’s already being used for sharing for instance (Cmd-s/Ctrl-s).
Couldn’t you make a directory, which is added to the PATH inside of the container and is mountable with docker? Something like “/apps” or “/programs”? I’m no docker expert but it should just work at least for pandoc. As it’s seems to be fully statically linked. And I would guess most of the stuff that finds use cases here can be (or is already) statically linked without bigger issues.
In my case, converting a Silverbullet page to a pdf doesn’t really need to be done inside of silverbullet. A simple terminal command does the trick. Why incorporate that functionality into Silverbullet at all? As I understand it, Silverbullet isn’t able to read PDFs at this time anyway. I see no purpose in doing this inside of Silverbullet. It has no real bearing on the functionality of the PKM or notes in Silverbullet from my perspective. An entry in the documentation with instructions how to do this should be enough. I think the KISS principle would apply here.
I guess the workflow of just having a one key press command is a little faster than Download → Open Terminal → Think about and type pandoc command → PDF.
Tbh it doesn’t really matter in my opinion if pandoc is bundled in the docker image. I have docker images which are close to 1GB or even more and I’ve never really noticed big differences in working with them, let alone have space concerns on my sever.
My concern is primarily that having it directly bundled doesn’t really seem hackable or customizable for other apps which someone may need and it also isn’t really “scalable”.
This seems excessively complicated. Completely hand building an image everytime. I don’t exactly know how zef goes about reinstalling, but I guess he modifies and existing image using docker exec and then docker commit to reuse it. Which is a lot easier than getting a docker file, modifying it, building and so on.
And about that
I think it is decently easy to set up (search executable, wget, add volume to docker-compose/command) and the big advantage is that it persists between images without any work and doesn’t change the image size
This is a potential rat hole not worth going into, but if we want to solve the general case: when using package managers like APT to install software, bits and pieces fly all over the disk (/usr/bin, /usr/lib etc.) it’s not so easy to localize that and mount it in. There’s alternative package managers that are better suitable for this stuff, but again: this is not a business I have interest getting into.
Most users will not be upgrading SB every day, so my short-cut proposal is along the lines of:
Have a “ensure package” type API that checks if a particular package is installed, if not, installs it right then and there (think apt install -y <package>).
You could also just hook into the browser if you want a PDF. Just call the browsers print function, then clean up the page a bit, safe as pdf, viola: PDF.
JS: window.print()
CSS (to clean up the page): @media print { do what you want to hide the top header stuff, etc}
I’d love to have Pandoc in the Docker container. Provides great features that add value to it. Keeping it slim is fine, but I’d consider Pandoc essential.
Different Docker versions+tags with various functions could work, but not sure how much work it would be (pipeline + documentation). I’d stick to one image tho.
I don’t know how it is implemented, but linuxserver.io has plugins (docker mods) for their images, so you can just add-on whatever you need. Might be more effort than it is worth though.
