scripts-to-rule-them-all VS django-sql-dashboard

Personally I like https://github.blog/2015-06-30-scripts-to-rule-them-all/ as a pattern and then let the authors do whatever crazy thing they want from there. In my experience, 99% of repos never move past using simple shell scripts with a few common functions with that pattern, and things are kept fairly simple. A select few repositories tend to mature enough that they are able to invest in swapping towards something more testable than shell scripts, and then you just have a couple people who stick to invoking `make` from the scripts but it's fine and nobody has to think about it except them. We don't stick to that exact set of scripts, but find that as long as you don't use more than like 10ish entrypoints in `script/*`, and have at least `script/bootstrap` it's fine.

I dig the general idea, but question the value add over a directory of `scripts` that follow sane conventions (ie `script/test`, `script/build` etc). Is the main thing that you can do `just -l` to see available commands? I have never really reached for `make` when I've had a choice, as I've done mostly ruby, JS, or java where you have more sane, humane tools (i.e. Rake, Yarn, Maven though that one is never fun).

My general approach is every repo should have something that follows https://github.com/github/scripts-to-rule-them-all, written in sh (maybe bash, its 2023), linted with shellcheck. When you need something fancy Rake is great or grab some nice bash command line helper and source it from all your scripts. Is a command listing really worth another dependency over what you get from `ls script` or `cat script/README` ?

Afaik AzDo cannot run tasks concurrently. From having had to work with azure pipelines I would highly suggest to use the github approach of Scripts to rule them all and avoiding predefined tasks unless absolutely necessary(Things that are complicated to implement and solutions already existing.

GitHub have a pattern for this called "scripts to rule them all" - https://github.com/github/scripts-to-rule-them-all - I've not fully adopted it yet but I probably should, it looks very well thought-out.

People at Github made an attempt to fix this situation: scripts to rule them all. The idea is to have common set of executable scripts for common developer tasks in a script/ directory in the root of every project:

https://github.com/github/scripts-to-rule-them-all

I have a sister project to Datasette called Django SQL Dashboard which works against PostgreSQL databases: https://django-sql-dashboard.datasette.io

It used Django for the authentication layer but can otherwise work against any PostgreSQL database.

I partly built it to help explore what Datasette could look like if it expanded to work with more databases than SQLite. That's still something I'm considering doing in the future, via a plugin hook, but it's not on my short-term roadmap.

Reusable apps do exist (I released one myself a few months ago, https://django-sql-dashboard.datasette.io) but in most projects apps are single-use only - at which point they become little more than a code organization tool.

I use documentation systems that publish the documentation from the repo to a website. Most of my projects use Sphinx and reStructuredText for this, but I recently tried MyST (Markdown for Sphinx) and I like that a lot.

Some examples:

- https://docs.datasette.io serves documentation from https://github.com/simonw/datasette - which has documentation unit tests here: https://github.com/simonw/datasette

- https://django-sql-dashboard.datasette.io/ serves from markdown in https://github.com/simonw/django-sql-dashboard - I don't have documentation unit tests for that yet

Weirdly my Django SQL Dashboard project fits the bill a bit here: you can build up a "dashboard" (which is a tiny bit notebook-like if you squint at it the right way) with multiple SQL queries on it, and save that either as a bookmark or as a "saved dashboard" with a URL.

https://django-sql-dashboard.datasette.io/

In my own work I've been using it for the kind of things that I would normally use a Jupyter notebook for - gathering together research on problems I'm trying to solve.

It's hand-written CSS - there's not much of it: https://github.com/simonw/django-sql-dashboard/tree/01bb7e60...

I've been building a tool for this over the past couple of months called Django SQL Dashboard - it currently only works with PostgreSQL and you need to create a read-only database connection, but it then provides an interface for executing any bookmarking SQL queries plus some basic visualizations: https://github.com/simonw/django-sql-dashboard