I just published v7 of `sane`, a single-file command runner written completely in vanilla Python. Quoting from sane's manual page:
> # Why use sane?
> Sane is 1. extremely portable, and 2. low (mental) overhead. This is because (1.) sane is fully contained in a single Python file, so you can (and should!) distribute it alongside your codebase, and (2.) sane is vanilla Python. The second property makes sane extremely expressive -- in fact, sane can do anything Python can -- and prevents the introduction of more domain-specific languages.
> Of course, with great power comes great responsibility, and sane is trivially Turing complete; that is, after all, the point. Therefore, there are more (and more unpredictable) ways to fail critically. But, as Python has shown over the years, this flexibility is not much of a problem in practice, especially when compared to the advantages it brings, and given that other, more structured, tools are still available to be used in tandem.
Sane is pretty magic; calling "import sane" is enough to get started. This does come with its caveats, but this magic can optionally be disabled. Sane is also prepared to make use of concurrency (within the limits of Python): its topological sort algorithm identifies tasks that can be run in parallel, which can be activated with a Make-like "--jobs" flag.
Another focus point of sane is ergonomics: just about everything the user (as in, you) passes to sane is validated, and reflection is used to try to identify exactly the source of error and provide the user with specific and helpful feedback (and even an explicit solution, where possible). Here, Rust was very much an influence.
I'd submitted a previous version of sane to Show HN before, but v7 is a complete re-write, down to the documentation.
I don't expect sane to replace Make or other bigger scale or specialised build solutions, but I do think it can be a good option for small-scale projects or prototypes, and everything that can benefit from portability.
No comments yet.
