Experimenting with just

I took some time this weekend to experiment with just—a modern, make-inspired command runner. I’m interested in using it for managing the routine tasks of the Cifonauta database (a Django-based app), which are currently handled by Fabric.

Fabric is a Python library for running shell commands locally or remotely via SSH. I use it for interacting with the Cifonauta’s servers, like fetching the latest database from production or running the deployment routine after code updates.

Although Fabric works mostly fine, I’ve encountered a few command quirks over the years. I also often get confused when creating tasks because of all its lower level libraries (Invoke, Paramiko, Invocations, and Patchwork…). So, in the back of my mind, I’ve been roaming for a simpler alternative.

just seems to have a nice set of features and appears to be gaining some momentum lately.

Justfile‘s syntax is similar to that Makefile‘s. It was straightforward to create some recipes for the standard manage.py commands of Django, like runserver or shell. Here are a few of them:

# Cifonauta's justfile

# Set the default shell to bash
set shell := ["bash", "-cu"]

# List all available recipes
default:
@just --list

# Run Django development server
runserver:
@echo "Starting Django development server..."
python manage.py runserver

# Run Django shell
shell:
@echo "Starting Django shell..."
python manage.py shell

# Run Django database shell
dbshell:
@echo "Starting Django database shell..."
python manage.py dbshell

# Run Django makemigrations
makemigrations:
@echo "Making migrations..."
python manage.py makemigrations

# Run Django migrate
migrate:
@echo "Applying migrations..."
python manage.py migrate

# Run Django collectstatic
collectstatic:
@echo "Collecting static files..."
python manage.py collectstatic --noinput

# Run Django test
test:
@echo "Running tests..."
python manage.py test

I run the manage.py commands every time I work on the Cifonauta code. They are simple enough, but running just runserver or just migrate is even simpler and feels semantically right. And the autocomplete is also snappier than the standard django_bash_completion. I liked it.

A note: just prints the command itself to the terminal by default. Adding the @ in front hides the command; only the output is shown when running the recipe.

The first issue I had was trying to activate Cifonauta’s Python virtual environment automatically for each of the recipes above. Based on intuition, I created a recipe to activate the environment and added it as a dependency to other recipes. However, this didn’t work out.

It turns out that each line in just runs a new shell instance. After digging a bit, the solutions I found were complicating the code too much, so for now, I’m sticking with activating the environment myself beforehand—it’s quick enough (a one-key alias).

After this initial setup, I started migrating some fabfile tasks of the Cifonauta workflow to justfile recipes. One very nice feature I discovered is that you can run a just recipe in any language using shebangs. Different from regular recipes, the variables will persist across lines like in a standard script.

Here’s a simple Bash recipe to dump the local database to a file for backup:

# Backup local database
backup-local-db:
    #!/usr/bin/env bash
    echo "Dumping local database to file... ({{dbname}})"
    set -euo pipefail
    mkdir -p {{local_bkp_dir}}
    FILEPATH="{{local_bkp_dir}}/$(hostname)_{{dbname}}_$(date +%Y-%m-%d_%H%M).sql.gz"
    pg_dump {{dbname}} | gzip -c9 > "$FILEPATH"
    echo "Backup created: $FILEPATH"

And this one is a bit more complex as it runs a couple of commands remotely via SSH to get the latest production database.

# Fetch latest database from production
get-production-db:
    #!/usr/bin/env bash
    echo "Fetching latest database from production..."
    set -euo pipefail
    mkdir -p {{local_bkp_dir}}
    LATEST_DBNAME=$(ssh {{user}}@{{prod_server}} "readlink -f {{prod_bkp_dir}}/latest.sql.gz")
    FILENAME=$(basename "$LATEST_DBNAME")
    scp {{user}}@{{prod_server}}:"$LATEST_DBNAME" {{local_bkp_dir}}/"$FILENAME"
    echo "File copied: {{local_bkp_dir}}/$FILENAME"

There was only one idea left that I wanted to test: can I run some code from the Django app within a recipe? I made a test recipe to count the number of taxa in our database using the --command parameter of manage.py shell and it works!

# Test recipe for counting taxacount-taxa-test:@echo "Counting taxa..."@python manage.py shell --command "\from meta.models import Taxon;\taxa = Taxon.objects.all();\print(f'Total: {taxa.count()}')\"

While this type of query is probably better as a standard Django management in the long term, just recipes can be a handy shortcut to quickly draft and test commands before they graduate to the codebase.

To summarize, just feels promising. And it’ll most likely be easier to maintain than Fabric, since I can just create recipes in Bash or Python. But let’s see how it goes. I still need to migrate other, more complex tasks like the staging and production deployment routines, which will be some work.

—
URL: https://brunovellutini.com/posts/just-experimenting/