Polymaths.social

but she had to quit because of health and because "every book doesn't have to end in a groin punch

One of the reasons my copy editor stopped was because I kept making her cry at the end of my books. I believe the term "ugly cry" was used a few times.

Which is great, if you want a book that rips your heart out. Less so if you are looking for a happy ending. One of there reasons I made Allegro and some of the later stories more cheerful was because of that.

Interesting side note, Sand and Bone is probably the one book I have read that is able to give me a "good cry". There rest of the family can watch The Incredible Journey or Next Gen or any number of movies and get it out. I needed to write 180k words to get emotionally involved with a character to the point I could crack a tear.

Trauma sucks.

https://polymaths.social/@dmoonfire/statuses/01M34MZB4X0V3BCY318KZW19EN

Since I don't really have someone to talk to, I figured I'd talk to an "empty" room and see if they make sense. This comes up since I had to update mfgames-conventional-commit (https://src.mfgames.com/mfgames-git/mfgames-conventional-commit-rs) because one of the dependency packages points to a bad host, it was causing problems with my build servers¹.

So, I figured if I'm going to be giving the program a little love, I should fix a problem I've noticed.

At the moment, I have a sub-command that lets me update files to set the version number in C# or update the package.json. This is useful for say tagging Git, push up, and basically taking into the semantic release components I like when I stopped being all-in the Node environment.

Which is fine, but when I'm building a program/novel, I need to figure out the version before I do the build process so it can be baked into output files or on the title page, but then want to do all that git tagging of I use just release or something like that.

But I haven't implement that. I kind of tried to do it with the "always_run" flag, but that didn't work as well as I wanted to (though, it does have some useful aspects).

{
    "$schema": "https://mfgames.com/mfgames-conventional-commit-rs/schemas/v0.json",
    "packages": {
        "default": {
            "updates": [
                {
                    "always_run": true,
                    "script": "echo hi {package} flatten {flatten_version} detail {detail_version}"
                }
            ]
        }
    }
}

So I'm thinking about adding an --operation name option that lets me only run commands.

{
    "$schema": "https://mfgames.com/mfgames-conventional-commit-rs/schemas/v0.json",
    "packages": {
        "default": {
            "updates": [
                {
                    "always_run": true,
                    "operation": ["pre-build", "post-build"],
                    "script": "echo hi {package} flatten {flatten_version} detail {detail_version}"
                },
                {
                    "operation": ["post-build"],
                    "script": "echo I only run after the build if there is a version change"
                }
            ]
        }
    }
}

That would let me do mfgames-conventional-commits update --operation post-build or something like that.

That might work?

Well, this is the first time I've written a Rust crate that is not directly in the same project. I hit the Rule of Three with writing a table formatter for CLI commands (which I'm up to five copies now):

dmoonfire@hunip:mfgames-cli-table main v0.1.0 2s 
2026-09-18T20:54:56> just example-basic --
 name   value 
 alfa   1     
 bravo  2     

dmoonfire@hunip:mfgames-cli-table main v0.1.0 
2026-09-18T20:55:14> just example-basic -- --markdown
| name  | value |
|-------|-------|
| alfa  | 1     |
| bravo | 2     |

dmoonfire@hunip:mfgames-cli-table main v0.1.0 
2026-09-18T20:55:17> just example-basic -- --json | jq
[
  {
    "name": "alfa",
    "value": 1
  },
  {
    "name": "bravo",
    "value": 2
  }
]