Salotz's Homepage

On git-hook managers

Samuel D. Lotz — Sat, 17 Dec 2022 16:11:58 GMT

Using git-hooks is a common method used to enforce constraints, standards, and static quality of a code bases. By checking for things at the point of the "pre-commit" git hook it allows for a faster feedback loop for the developer, rather than waiting for it to fail in CI.

It is common to use a hook manager to automate the installation of the hooks into .git/hooks and to pull them from either a remote repository of common hook implementations or generate them from a simple kind of configuration.

This page (githooks.com) provides a nice third-party overview of git hooks along with the most commonly used hook managers.

I was a little late in adopting git-hooks myself and have finally sat down and figured out a good workflow for my tastes.

At least in my little bubble the most common hook manager is pre-commit. I've created repository templates that use it, bootstrap it, and integrate it with CI such that it is by default reproduced locally to avoid version drifts ¹.

The Problem with `pre-commit`

I found pre-commit to be pretty frustrating most of the time. When I imagined a hook manager I expected that it would be a pretty simple piece of software that simply took some commands to run, or potentially downloaded some scripts from a git repo. pre-commit on the other hand is much more complicated and actually takes on the responsibility for downloading the hook scripts from a special "package" format, creating individual virtual environments for them, and a host of other options for controlling their behavior. All of which can break in non-obvious and confusing ways ².

I lived with the inconveniences for a while as it seemed that everyone around me was happily using it and I must have been missing something. Unfortunately, I don't think this to be true anymore and I'm convinced that pre-commit is just adopted in cargo cult fashion. Perhaps there is even a conflation that pre-commit is git hooks.

Regardless the straw that broke this camel's back was setting up Python type checking to be run as a git hook. Because pre-commit hooks are run in their own contained virtual environment they cannot easily import either local code you are working on (for type stubs) and if you want to inject third-party type stubs you need to explicitly write them all down in the pre-commit configuration. The issue is that I already have all this done using other tools or scripts which are the primary entrypoints for working on the project. I don't want to have to maintain a duplicate listing just for my hooks to work. Managing dependencies is hard enough without having another place to duplicate them.

This is really an issue with separation of concerns and composability. Personally, I take great care and choose my tools such that I can generate reproducible development environments such that they are composable with many other tools. pre-commit is in opposition to this and wants to control everything. This is useful for simple static analysis tools like black which do not need to be installed alongside your code and can act on your code as simple text blobs. However, when you want to do more complex things that require pulling in extra dependencies and actually importing builds of your code pre-commit just ceases to be simple and is in your way.

Secondly, because pre-commit thinks it runs the show it ends up infecting the rest of your development automation. I typically give all my projects some kind of "task runner" which gives a high-level and abstracted entrypoint to doing repetitive tasks. This typically takes the form of a Makefile, but I've also used and can recommend invoke and pydoit to accomplish the same thing.

Here is an example of a Makefile with some common tasks without using pre-commit:

clean: ## Clean temporary files, directories etc.
    hatch clean
    rm -rf dist .pytest_cache .coverage
    find . -type f -name "*.pyc" -print -delete
.PHONY: clean

format: ## Run source code formatters manually.
    hatch run -- black src tests
    hatch run -- isort src tests
.PHONY: docstrings

validate: format-check lint docstring typecheck ## Run all linters, type checks, static analysis, etc.
.PHONY: validate

format-check: ## Run code formatting checks
    hatch run -- black --check src tests
    hatch run -- isort --check src tests
.PHONY: format-check

lint: ## Run only the linters (non-autoformatters).
    hatch run -- flake8 src tests
.PHONY: lint

docstring-check: ## Run docstring coverage only.
    hatch run -- interrogate src tests
.PHONY: docstring

typecheck: ## Run only the type checker (requires mypy)
    hatch run -- mypy --strict src tests/utils
.PHONY: typecheck

In this scenario make validate is the canonical way to run all the various linters. This should be the only entrypoint to these tasks so that we don't get duplication and drift in different environments, e.g. locally, CI, and git-hooks.

Using pre-commit however I cannot call these Makefile tasks in any practical means. So what ends up happening is that you need to replace commands in the tasks with explicit calls to pre-commit to run things for you. E.g.:

.pre-commit-config.yaml

repos:
- repo: https://github.com/psf/black
  rev: 22.6.0
  hooks:

  # run the formatting
  - id: black
    alias: black-format
    files: ^(src|tests)
    name: "Format: black"

  # just check
  - id: black
    alias: black-check
    args: [--check]
    files: ^(src|tests)
    name: "Check: black"
    # don't run unless done manually
    stages:
      - manual

Notice the rigamarole you have to go through to run a single hook type in multiple ways.

Makefile

format: ## Run source code formatters manually.
    pre-commit run --all-files black-format
    pre-commit run --all-files isort-format
.PHONY: docstrings

So now pre-commit is not just the thing that runs things on your behalf at specific time (the essence of what git hooks are) it is now an integral part of how you manage dependencies for your project.

The Solutions

At this point I decided I needed something better. I want a hook manager to be:

Very easy to install and bootstrap for newcomers to a project.
Ability to run arbitrary commands and integrate with any virtual environment manager and task runner I'm already using.

For 1 this is very important because you do not want to frustrate people before they actually start working on your code. At this stage it should be so easy that you should be able to write a task or shell script that can bootstrap the manager. So ideally that means a single executable file.

I narrowed it down to two hook managers that seemed to accomplish this:

I ultimately decided on lefthook but Autohook was very tempting as well. Autohook is a single bash script that you can just download. You operate it by maintaining a hooks directory that you dump executables into, and control which hook stage and order they run in with symlinks. All Autohook does is place these into .git/hooks. I don't think it gets any easier than that. Looking at the code as well its just a bit more robust version of the shell script you would have written yourself without a plethora of hook managers to choose from.

What I liked about lefthook was that its a Go project and comes as a single binary executable which is easy to download and immediately use. It should also be easier to support on platforms like Windows since there is no reliance on a POSIX-like shell. It also provides packages for just about every package manager, and even for language specific ones like pip and npm.

Second, its dead simple in its operation. You write a lefthook.yml file which specifies the hooks you want to use. Here is mine:

lefthook.yml

pre-commit:

  parallel: true
  commands:

    format-check:
      run: make format-check

    lint:
      run: make lint

    docstrings:
      run: make docstring-check

    typecheck:
      run: make typecheck

The top-level groups are for each hook stage and here I am only configuring the "pre-commit" stage. Under the commands section I list out the name of each hook and how to run it. Since I already have the business logic for these in my task runner its as simple as wiring them up!

This is great, its a hook manager thats doing only one thing, managing hooks, and doing it well. It didn't require any refactoring of anything else in my project, it runs the hooks in parallel and provides a bunch of other useful options to control its behavior.

Conclusion

Thats it! I've not even used lefthook for a full day and its already much improved my life:

I now can easily do complex typechecking with a git pre-commit hook,
I don't need to run my hook manager in CI, just my task runner,
I don't need to worry about yet-another system with caches and virtualenvs,
I can run hooks more quickly and in parallel

I highly recommend it and encourage you to question cargo cult adoption of sub-par tooling like pre-commit in other areas.

A lot of times I see impatient developer's just ignore these kinds of issues and get by just fine for a long while. I have the unique (mis)fortune of typically running into these kinds of issues very quickly if not immediately and this was the same for using pre-commit in my CI pipelines. So thats just to say that, yes you really do need to worry about this as it will bite you sooner or later. ↩
For example ↩

Demos

Samuel D. Lotz — Sun, 27 Nov 2022 22:19:06 GMT

There is a new section on my webpage dedicated to demos that can be run in the browser. Check out the first one: Godot 2D Creeps.

Its not very interesting as it is just the 2D game from the Godot documentation, but I am posting here as a proof of concept.

Presentation at Silicon Therapeutics

Samuel D. Lotz — Wed, 09 Dec 2020 18:17:06 GMT

I was lucky enough to be able to present my work this week at Silicon Therapeutics, thanks for having me!

I've made the slides available in this repository on gitlab at this location as a PDF.

Presentation roughly covers these topics:

Kinetics oriented drug design
Description of the Weighted Ensemble (WE) class of enhanced sampling algorithms
Motivation and design of the wepy framework for performing and analyzing WE simulations as well as prototyping new methods.
Results for my PhD research into ligand unbinding transition state structure for clinically relevant target soluble epoxide hydrolase.

Comments

Comments are implemented as a mailing list hosted on sourcehut: https://lists.sr.ht/~salotz/salotz.info_comments-section

Comments are for the whole website so start your subject line with: [sitx_wepy_talk] for this post.

Cron alternative with runit and snooze

Samuel D. Lotz — Fri, 23 Oct 2020 15:16:36 GMT

I have tried many times to use cron effectively, but ultimately this ends in failure each time. Lets look at why I find cron onerous and a solution I came up with¹.

Skip to this section if you just want to see the solution.

Non-Issues

Conceptually specifying when to run things with a special syntax is not a bad idea and not why I find cron hard to use.

Just as a reminder this is what a cron job I found in my system for the dma mail agent:

*/5 *	* * *	root	[ -x /usr/sbin/dma ] && /usr/sbin/dma -q1

The meaning and examples for the timing specs are well known and not really an issue here. There are lots of alternatives that try to improve on this, this is not one of them (although it is different in this regard).

Sys-Admin Orientation

My first issue with cron is that it is inseparable (or at least practically so) from the base *nix system. That means you can't run it as a user as it is meant to be the scheduled thing runner for a multi-user system. So while you can have the system run things on behalf of you as a user you can't really control it.

In this day and age, multi-user systems are becoming pretty rare outside HPCC systems in academia and gov't labs. For most people they want to run simple recurring tasks on their desktop, laptop, VPS server, or maybe even a homelab server. In all these cases user's are usually simply mechanisms for implementing access control and not for distinct human entities.

This kind of sysadmin oriented baggage is pretty pervasive in *nix systems and cron is not alone here.

Because cron is so deeply embedded into the lizard brain of *nix it is necessary to have a properly running and configured cron for the stability of your system.

As a reasonably competent user of linux desktops, the thought of inadvertently messing up /etc/crontab and its ilk is enough to keep me away from it.

For instance where exactly am I supposed to put a cron job? On Ubuntu 20.04 (KDE Neon actually) I see this in my /etc dir:

--> ls /etc/ | grep cron
anacrontab
cron.d
cron.daily
cron.hourly
cron.monthly
crontab
cron.weekly

Additionally this is highly variable distro to distro.

For instance here is part of the man page for cron on my system:

DEBIAN SPECIFIC
       Debian introduces some changes to cron that were not originally available  upstream.   The  most
       significant changes introduced are:

       —      Support for /etc/cron.{hourly,daily,weekly,monthly} via /etc/crontab,

       —      Support for /etc/cron.d (drop-in dir for package crontabs),

       —      PAM support,

       —      SELinux support,

       —      auditlog support,

       —      DST and other time-related changes/fixes,

       —      SGID crontab(1) instead of SUID root,

       —      Debian-specific file locations and commands,

       —      Debian-specific configuration (/etc/default/cron),

       —      numerous other smaller features and fixes.

       Support  for  /etc/cron.hourly,  /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly is pro‐
       vided in Debian through the default setting of the /etc/crontab file (see the system-wide  exam‐
       ple  in crontab(5)).  The default system-wide crontab contains four tasks: run every hour, every
       day, every week and every month.  Each of these tasks will execute run-parts providing each  one
       of the directories as an argument.  These tasks are disabled if anacron is installed (except for
       the hourly task) to prevent conflicts between both daemons.

This goes on for several more paragraphs of neckbeard-speak that I don't pretend to understand. Am I running anacron? Why? What is run-parts? Its obvious a lot of this is for security purposes that are important in enterprise environments that a professional sysadmin is paid a hefty salary to comprehend. So there is probably a simple answer to this mess, except I don't have direct access to the people who made this mess to ask them.

This is a scenario where reading the manual leaves me more confused than I started. I'll probably get chastised for overcomplicating things. In pre-emptive response I will leave this quote from James Clear's mailing list I got today:

To simplify before you understand the details is ignorance.

To simplify after you understand the details is genius.

I'm in the former category.

I would like to schedule backups to happen everynight, but I would rather not upset the fragile balance distro maintainers have made to keep your desktop running "smoothly".

Cron is simply not meant for a simple user like me.

Control & Supervision

The second major problem I had with cron was the real lack of control you have over it. You write text into the file and cron goes off and does its thing, just like Ritchie and Thompson intended.

Everyone with a modicum of understanding of why databases exist sees the obvious issues with inconsistency that this has. So no longer can you just edit /etc/crontab but rather you are supposed to go through helper tools (like crontab) which does all manner of locking and gatekeeping to desparately pretend its a database.

Using tools that automatically open up editors is another pet-peeve of mine since you now are bringing in a lot of other assumptions about the configuration of your system. I hope you know how to safely close files in nano and vi! Further, I like to keep all my configurations in a central configuration directory that I can use normal version control etc. How am I supposed to "load" these into the cron jobs without manually copy-pasting, at least if your going by the "manual". Aren't these systems supposed to be scriptable? ²

As we'll get to in the actual solution I'm presenting here, the loading, unloading, restarting, pausing etc. of jobs is eerily similar to the feature sets used in PID 0 programs like systemd.

Indeed systemd has a similar timer system, which has much better control, but again suffers from being sysadmin oriented. Also writing unit files blows. I do it, but I try not to.

Back to cron though, the only solution to this I have found is to install a program called cronitor, which is like a freemium tool that really isn't that scriptable either due to the (very nice) terminal UI. This is useful, but I don't really see this as something I can expect to have going into the future on all my systems.

Observability & Logging Utilities

I was able to get through all the issues above through sheer force of will, but ultimately I was done in by the necessary interaction of cron to two even more obtuse systems in *nix: email and logging.

Email is sort of baked into cron and from what I can tell is the main way of getting notifications that running things had issues.

For instance if your trying to run a script and you got the path wrong you'll need a working email server for cron to send a message. And if you give a mouse a cookie…

Then you'll need to make sure your mail boxes for the users on your system are working, you know where they are and you have a client for reading them.

This seems like a huge dependency to have to just get a message about a job having an error in it?

Shouldn't there just be a log file I can pop open in a text editor (like Ritchie and Thompson intended goddamit)?

For me and I'm sure many others, I've never had a need to interact with intra-system email. Even on the HPCC systems I worked in for my PhD this is basically an unused feature.

When you do get jobs running without error (and thus no reason to email you), you'll want to see their logs too.

In cron, its completely up to you to create and manage the lifecycle of logs in your system. While in theory this is a good thing since it allows you to not be locked into something you hate, in practice for non-neckbeards it involves you having detailed knowledge of yet another complex subsystem.

I simply don't know where to even start here. The cron docs say to use rsyslogd, which I don't know how to use. Furthermore, my system is using systemd which has nice commands that show you the latest in the logs. Is this subsystem disjoint? It wouldn't suprise me that they would jump through different calcified hoops to keep 40 year old things running.

Again there is probably a simple answer to all this, but its one that reading the man page can't get you. I don't log a lot of stuff, but mistakes happen and logs can fill up a / partition scarily easy.

Runit tutorial

I've contemplated and even tried a few alternatives to cron. This one was discovered while throwing stones at other birds. I was pleasantly surprised.

Basically it boils down to using a process supervisor called runit and a fancy big brother to the unix sleep command called snooze.

Runit was originally meant to be a replacement for older init systems like sysvinit that is cross-platform as well as very simple and not requiring many libraries. This was to suite it as part of the core system to bootstrap everything else (think cron and sshd etc.).

While these are nice characteristics they aren't killer for us here. However, nowadays its pretty popular with the anti-systemd crowd. Its an option for init systems in Gentoo and others and is the default in Void linux. Besides its simplicity it is pretty easy to get up and configured and you just run a few shell scripts to get everything going.

I have a few complaints

the documentation is kind of nonlinear and doesn't give you a walkthrough of how to use the whole system ³.
commands are disjointed and spread between a number of executables and use of standard unix commands like ln and rm.

The second point is actually a feature where each of the little components can be used standalone. However, this makes it a little more confusing to wrap your head around and I found myself constantly reviewing my notes to know which command to use.

I solved this with a few shell functions, but I would like to see a wrapper CLI to make it a little centralized conceptually (and to add a few convenience features) for those that would want it.

Reading these articles also helped in understanding it:

Even after reading these I had to muck around and figure a bunch of little details out so I thought I would throw my own little tutorial on the pile to hopefully save some people's time and make runit a little more approachable.

Luckily on Ubuntu 20.04 its really easy to get runit installed and running as a systemd service. Just install using apt:

sudo apt install runit

This even starts the service:

sudo systemctl status runit
sudo journalctl -u runit

Normally there are 3 stages (i.e. states) runit has:

Single run tasks on startup
Process supervision: starting, stopping, restarting services
Shutting services down as the system goes down

Because we aren't using runit as a PID 0 init system, we only care about stage 2 & 3. The apt installation takes care of this for us thankfully.

So you should see the following directories appear:

/etc/runit: stages and runlevel stuff, ignore this (for now).
/etc/sv: The services directory, this is where you author things.
/etc/service: This is where "enabled" services are put.

I'll call these different directories by the environment variable I refer to them as. I put this in my ~/.profile:

## runit known env variables

# the active service directory to query for state, this is what it is
# default, but I like to set so its easier for me to disable services
export SVDIR="/etc/service"

# SNIPPET: the normal wait time
# export SVWAIT=7

## my vars, not recognized by any runit tools

# this is the standard directory of where services are put for the
# system. The SerVice LIBrary
export SVLIB="/etc/sv"

# log dir
export SVLOG_SYS_DIR="/var/local/log/runit"

To define a service you make a directory in SVLIB with some specially named shell scripts. Mine has these directories in it:

--> ls $SVLIB
backup  hello  printer_live  recollindex  test_env

Each one is a specific service. Lets first look at hello to get a simple picture of what these are:

--> ls $SVLIB/hello
finish  log  run  supervise

The most important one is run which is a shell script:

#!/bin/sh

# run the service
while :
do
    echo "Hello"
    sleep 2
done

This just prints "Hello" to stdout and then waits 2 seconds.

This service isn't being run yet. For that you need to put it into the SVDIR:

sudo ln -s -f "$SVLIB/hello" "$SVDIR/"

You can check the status of the service with the sv command:

--> sudo sv status $SVDIR/hello
run: /etc/service/hello: (pid 664634) 193s

You can check the status of all services similarly:

sudo sv status $SVDIR/*

If you see this:

--> sudo sv status $SVDIR/hello
down: /etc/service/hello: 1s, normally up, want up

There is something wrong with your run script.

Looking at sudo systemctl status runit and sudo journalctl -u runit could usually help me figure the issue out (no email!!!).

Once its working you should see the "Hello"s on the log for runit if you aren't logging this service:

--> sudo journalctl -u runit | tail
Oct 23 16:49:30 ostrich 2[664634]: Hello
Oct 23 16:49:32 ostrich 2[664634]: Hello
Oct 23 16:49:34 ostrich 2[664634]: Hello
Oct 23 16:49:36 ostrich 2[664634]: Hello
Oct 23 16:49:38 ostrich 2[664634]: Hello
Oct 23 16:49:40 ostrich 2[664634]: Hello
Oct 23 16:49:42 ostrich 2[664634]: Hello
Oct 23 16:49:44 ostrich 2[664634]: Hello
Oct 23 16:49:46 ostrich 2[664634]: Hello
Oct 23 16:49:48 ostrich 2[664634]: Hello

Next you'll have the finish script which is just what should be run at the end of the script:

#!/bin/sh

echo "Shutting Down"

We don't have anything to do really so we just write a message. But you could do cleanup stuff here if you want.

Last the logging spec. This is a subdirectory called log:

--> tree $SVLIB/hello/log
/etc/sv/hello/log
├── run
└── supervise [error opening dir]

1 directory, 1 file

Where again the run is a shell script:

#!/bin/sh

exec svlogd -tt /var/local/log/runit/hello

To keep things simple this is what you want. In general you could swap out different logging daemons other than svlogd (which comes with runit), but I don't see a reason to and this Just Works™. Basically runit will create this as a separate service, but just knows how to pipe around outputs now.

If you add these and then reload the services:

sudo sv reload $SVDIR/hello

You'll stop seeing "Hello" in the runit system log, and start seeing it in the log file we configured:

sudo less +F "$SVLOG_SYS_DIR/hello/current"
# or
sudo tail -f "$SVLOG_SYS_DIR/hello/current"

Before we go over configuring the logging daemon (that sysvlogd thing we ran in log/run) I should mention all those supervise dirs that were laying around.

These basically are the locks and other control data that runit uses to manage the services. Don't mess with them. They are owned by root anyways. One thing you can do if you think you messed things up is to disable the service and remove them all to start fresh:

sudo rm -rf $SVDIR/hello
rm -rf $SVLIB/hello/supervise
rm -rf $SVLIB/hello/log/supervise

Now one last thing is to configure the log. This file doesn't go in the service directory (SVLIB) but the directory where the logs are. So make this file SVLOG_SYS_DIR/hello/config and it should have something like this:

# max size in bytes
s100000

# keep max of 10 files
n10

# minimum of 5 files
N5

# rotate every number of seconds
t86400

# prepend each log message with the characters
pHELLO::

This lets you rotate logs and control file sizes. Its a really not nice file format but I will forgive them considering they aren't using any libraries for TOML or YAML parsing or such things. Again something I would improve on for non PID 0 usage.

With this all in place you'll see something like this in SVLOG_SYS_DIR/hello:

--> sudo tree $SVLOG_SYS_DIR/hello
/var/local/log/runit/hello
├── @400000005f929f2c12d2041c.s
├── @400000005f92b3043a84c42c.s
├── @400000005f92c6dd22d71b04.s
├── @400000005f92dab60d0ce77c.s
├── @400000005f92ee8f37dec1dc.s
├── @400000005f93026921e78ae4.s
├── @400000005f931643127f5bf4.s
├── @400000005f932a1d27cdd3b4.s
├── @400000005f933df70f77ffc4.s
├── @400000005f933e0a239542b4.s
├── config
├── current
└── lock

Where those ID named files are the rotated logs.

Now that we're done with the runit tutorial lets show you how to make a timer service that acts like a cron job.

Timer Services With Runit and Snooze

snooze was also available in the Ubuntu package index so we just install with apt:

sudo apt install snooze

Otherwise its very basic C so should be trivial to compile and install.

First lets just right a timer script that runs a command every 40 seconds seconds with sleep and then we can just replace sleep with snooze. Our run script is then:

#!/bin/sh

echo "Sleeping until time to run"
sleep 40

/home/user/.local/bin/run_thing

echo "Finished with task"

Because we are running this script as a service and the job of a service manager is to restart failing services, this script will just run over and over. There really wasn't a need for the while loop in our hello example.

Now to make this "cron-like" we replace sleep with snooze:

#!/bin/sh

echo "Sleeping until time to run"
snooze

/home/user/.local/bin/run_thing

echo "Finished with task"

Where the default of snooze is just to block until midnight every night (that is hour zero). So basically its just calculating how long it is until midnight and sleeping until then. Pretty simple right? Once snoozing is over the command will run the task will terminate, get restarted and then will snooze again until next time.

You can see all the options for configuring when snooze will sleep until in its docs and man page (this one is actually readable). But for instance you can set it sleep until 3 AM on Mondays and Thursdays:

snooze -w1,4 -H3

Something else I like to do is have it run a number of jobs in serial as a cycle. Where you would have to have multiple cron jobs to achieve this you can do it in one script with this method.

I have a two print jobs every week to keep the heads from drying out. Black and white on Monday and color on Thursday at noon.

#!/bin/sh

echo "Snoozing until time to print"
snooze -w1 -H12

echo "Printing black and white test page"

# black and white
lp /home/salotz/testpage_bw.pdf


echo "Snoozing until next print job"
snooze -w4 -H12

echo "Printing RBG color test page"

# color: RBG
lp /home/salotz/testpage_color_rbg.pdf

echo "End of run script job cycle"

With cron you'd have something like ⁴:

0 12 * * 1 salotz lp /home/salotz/testpage_bw.pdf
0 12 * * 4 salotz lp /home/salotz/testpage_color_rbg.pdf

So the syntax for snooze is actually pretty similar and perhaps a little cleaner and semantic.

So just to review: By avoiding cron we've avoided some of the most difficult and finnicky sysadmin tasks in linux, namely email and logging, and traded them for runit. I think its a fair trade and as we've seen setting up runit is trivial in Ubuntu (and likely other distros).

I can definitely see now why runit has fierce supporters. I'll definitely be using it for situations I would normally use systemd as well. While I'm not going to be running Void linux on my desktop any time soon its a good candidate for inside of containers.

Final Notes

As I mentioned I am not a grey-neckbeard and so if I've made any gross oversights in my claims, please let me know in the comments. I would love to like cron more.

Comments

Comments are implemented as a mailing list hosted on sourcehut: https://lists.sr.ht/~salotz/salotz.info_comments-section

Comments are for the whole website so start your subject line with: [runit_snooze] for this post.

Footnotes:

Well, the idea was hinted at in the snooze README but I put it together.

Every shell script is a scar:

master_tab="$(cat << EOF
$(cat $CONFIGS_LIB_DIR/cron/header.crontab)
$(cat $CONFIGS_LIB_DIR/cron/misc.crontab)
$(cat $CONFIGS_LIB_DIR/cron/my.crontab)
EOF
)"

# then write to the crontab file after cleaning it out
(crontab -r && crontab -l 2>/dev/null; echo "$master_tab") | crontab -

It only has How-To Guides and Reference according to this classification: https://documentation.divio.com/

⁴

No I didn't do that myself, of course I used this https://crontab.guru/.

Blog Launch

Samuel D. Lotz — Fri, 10 Apr 2020 14:19:54 GMT

Here is my obligatory blog launch post where I tell you about how I created my blog and so that there is at least one post here ;)

This Blog

I ended up choosing Nikola mainly because:

It's written and extended in Python (my default language)
It has pretty good support for Emacs Org-Mode markup via a plugin
Simple while still supporting basic blog & general purpose web pages

Nikola is basically a wrapper around doit with special functions for web pages.

doit is essentially a python programmable replacement for make, and just about every experience report with static site generators is that they are just fancy makefiles. QED

Future Posts

In future posts I hope to discuss some practical issues around:

Tools and tips for data science projects as applications and pipelines.
Managing dependencies, virtualenvs, repository structure, and release management for python projects.
Setting up and managing personal configuration and infrastructure in a linux environment.
Software architecture and design.

The goal of my posts will not be tutorials around how to use specific tools but rather how they all can fit together and integrate.

Potential Collaborations

Check out my list of projects. I am looking for others to test out and critique their design.

I also maintain a personal listing of: Request For Comments (RFCs) and Proposals For Software (PFS) in this repository (web page to come).

Thats it!

Salotz's Homepage

On git-hook managers

The Problem with pre-commit

The Solutions

Conclusion

Demos

Presentation at Silicon Therapeutics

Comments

Cron alternative with runit and snooze

Non-Issues

Sys-Admin Orientation

Control & Supervision

Observability & Logging Utilities

Runit tutorial

Timer Services With Runit and Snooze

Final Notes

Comments

Footnotes:

Blog Launch

This Blog

Future Posts

Potential Collaborations

The Problem with `pre-commit`