| 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" | |
| ) |
| 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 |
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.
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.
| #!/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=( |
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:
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.
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.
| 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 |