Soupault intentionally doesn't have a built-in web server, deployment automation, or a snake game (though a snake game may be added in future versions, stay tuned). That's the UNIX philosophy: do one thing and do it well. The big idea is to provide configurable workflows rather than force a workflow on you. Here's my workflow that you can use as an example if you like it, or disagree with and make your own—the choice is yours.
For a really low-tech workflow, you can just run soupault, point your browser to the build directory, and then copy generated pages by hand to the server. This will quickly get annoying if you update the site frequently.
There's a huge selection of tools to help you, and they can help you with many other tasks, not just with automating a soupault workflow, so you should learn about them if you haven't already.
Myself I'm using a pretty classic UNIX workflow with GNU Make. All the tools I use are cross-platform and will work on any OS, though you may want to go for OS-specific tools as well, like PowerShell on Windows or JCL batch jobs on IBM mainframes.
This is my makefile for this website:
BUILD_DIR := build # In practice it's in my ~/.local/bin SOUPAULT := soupault .PHONY: site site: $(SOUPAULT) .PHONY: assets assets: cp -r assets/* $(BUILD_DIR)/ .PHONY: all all: site assets .PHONY: clean clean: rm -rf $(BUILD_DIR)/* .PHONY: serve serve: python3 -m http.server --directory $(BUILD_DIR) .PHONY: deploy deploy: neocities push $(BUILD_DIR)
Remember that build directory path is configurable (the
build_dir option in
so it's a good idea to make it a variable, that's why I have
BUILD_DIR := build there.
I keep the soupault binary in my
~/.local/bin, which is in my
$PATH so I can just call it by name.
The main reason I made it a variable is that it's easy to try a dev build by editing just one line.
While you can keep assets (images, CSS stylesheets etc.) together with pages in
site/ and soupault will copy them
unchanges, I like to keep them separately. That's why I made an
assets target and specified it as a dependency for
For live testing the site, I use the web server that comes with Python. It's more than sufficient for testing and you can make it serve files from a directory in just one command.
deploy target for this site is just
neocities push—it uses
the Neocities CLI tool. For baturin.org, it's
rsync -a -e "ssh" $(BUILD_DIR)/ www.baturin.org:/var/www/vhosts/baturin.org since it's hosted on my own server.
There are no right or wrong ways to do it though. Use the tools that you like and that work well for you.