scop

Use --long-options if available. These are typically clearer to readers than short ones. They do make the command line longer than corresponding short ones, but in practice this is very rarely, if ever, a problem.

Use equals sign rather than space between a long option and its argument, if available, like --long-option=argument rather than --long-option argument. This is also for clarity as it's immediately clear that the argument is for the option rather than a positional argument for the command, and doing so tends to support pathological option argument cases starting with dashes better. It also renders better (subjective?) in many cases involving linefeeds, such as in various config file format and programming language arrays.

scop

diff -NruwB gopkg.in/yaml.v2@v2.4.0/decode_test.go go.yaml.in/yaml/v2@v2.4.1/decode_test.go
--- gopkg.in/yaml.v2@v2.4.0/decode_test.go	2025-12-08 11:38:41.644691341 +0200
+++ go.yaml.in/yaml/v2@v2.4.1/decode_test.go	2025-12-08 11:38:42.523274474 +0200
@@ -9,7 +9,7 @@
 	"time"
 
 	. "gopkg.in/check.v1"
-	"gopkg.in/yaml.v2"
+	"go.yaml.in/yaml/v2"
 )

scop

diff -NruwB gopkg.in/yaml.v3@v3.0.1/decode.go go.yaml.in/yaml/v3@v3.0.2/decode.go
--- gopkg.in/yaml.v3@v3.0.1/decode.go	2025-12-04 09:55:31.687862796 +0200
+++ go.yaml.in/yaml/v3@v3.0.2/decode.go	2025-12-04 09:55:33.170181040 +0200
@@ -832,10 +832,10 @@
 		if d.unmarshal(n.Content[i], k) {
 			if mergedFields != nil {
 				ki := k.Interface()
-				if mergedFields[ki] {
+				if d.getPossiblyUnhashableKey(mergedFields, ki) {
 					continue

scop

Since bash 5.1, PROMPT_COMMAND can be an array. That's nice, as it's easier to robustly operate on an array on per element basis than on a delimited string to that effect.

Adding

Things that add to the variable can coexist and just operate on it as they would normally do, whether they treat it as an array or a scalar, without doing extraneous checks.

The first gotcha related to this is that operating on an array variable as if it was a scalar operates on the array's first element.

scop

#!/bin/bash
set -euo pipefail
shopt -s globstar

allowfile=TODO-missing-signs.txt

# highly volatile, prefix of latest release's sha, https://github.com/sigstore/cosign-installer/releases
cosign_installer_latest_sha_prefix=f

searches=(

scop

Here's a list of settings and features for GitHub projects that I've found recommendable to pretty much every project. Some of them would be nice to be on by default by GitHub so new projects would have them right out of the box, but while they are not (they were not at time of writing), here we go, in no particular order:

CodeQL

Even if the project is not written in a supported language, GitHub Actions workflows are used by most. CodeQL supports checking them, which makes them a nice lowest common denominator.

scop

Why not install tests?

For the majority of users, test code is just waste of space and bandwidth. For example, for Home Assistant, in the full dependency set du -hc **/tests **/test reports 82M here (2020-10-24). Granted, most users don't install the full dependency set, so they are affected to a lesser extent, and that's a smallish fraction of the total dep set size, but still.

But isn't it good to install test code so it's around as a usage example? Test code is often not good code to be used as a general use example. It is often entangled with mockery, accesses things that should not be accessed in normal use to begin with, or accesses things in a way that is not supposed to be done outside of tests, etc, or all of that.

Isn't it good to be able to run tests suites on installed setups e.g. when diagnosing problems? Yes, that would be nice. But a bunch of things makes this less practical as it would seem on the surface.

• Test code can have dependencies that are not

scop

For the majority of users, test code is just waste of space and bandwidth. For example, for Home Assistant, in the full dependency set `du -hc **/tests **/test` reports 82M here (2020-10-24). Granted, most users don't install the full dependency set, so they are affected to a lesser extent, and that's a smallish fraction of the total dep set size, but still. 

Proponents of test code inclusion may say it's good to have it around as a usage example. But test code is often not good code to be used as a general use example. It is often entangled with mockery, accesses things that should not be accessed in normal use to begin with, or accesses things in a way that is not supposed to be done outside of tests, etc, or all of that.

Test code can have dependencies that are not the package's runtime dependencies. When these dependencies are not installed along with the package and its real runtime dependencies (hopefully at least these are always excluded!), users must take measures to install them before they are ab