Update blog, update workflow to integrate custom blag fork

- custom blag fork will render markdown with footnotes and strikethrough

.gitea/workflows/production/build-deploy-docs.yml

@@ -39,6 +39,9 @@ jobs:
           apt install -y curl tar p7zip-full python3.11 pip pipx
       -
         name: Install pipenv, build blog...
+        env:
+          PIPENV_USER: ${{ secrets.PRODUCTION_REGISTRY_USERNAME }}
+          PIPENV_PASS: ${{ secrets.PRODUCTION_REGISTRY_TOKEN }}
         run: |
           pip install pipenv
           pipenv install

Pipfile

@@ -3,8 +3,13 @@ url = "https://pypi.org/simple"
 verify_ssl = true
 name = "pypi"
 
+[[source]]
+url = "https://$PIPENV_USER:$PIPENV_PASS@gitea.raer.me/api/packages/freyjagp/pypi/simple"
+verify_ssl = true
+name = "gitea"
+
 [packages]
-blag = "*"
+blag = {version = "==2.3.0", index = "gitea"}
 
 [dev-packages]
 

content/2024/01/18/increasing-complexity.md

@@ -0,0 +1,129 @@
+title: Increasing complexity
+description: A small issue snowballs because I want independence
+tags: technical, gitops, devops
+date: 2024-01-18 01:09
+
+# Increasing Complexity
+
+__START TIME: 2024-01-18 01:09__
+
+A couple of small issues with formatting showed up in the [last post](../17/post-01.md)
+
+Footnotes...
+
+![Footnote issue 1](images/footnote01.png)
+![Footnote issue 2](images/footnote02.png)
+
+...and strikethrough...
+
+![Strikethrough issue](images/strikethrough.png)
+
+do not render right with blag. The solution is superficially quite simple. I've already got it working locally. All you have to do, is install a python package called `pymdown-extensions` and change a single array in blag's source code:
+
+```python
+
+# from this...
+
+def markdown_factory() -> Markdown:
+    """Create a Markdown instance.
+
+    This method exists only to ensure we use the same Markdown instance
+    for tests as for the actual thing.
+
+    Returns
+    -------
+    markdown.Markdown
+
+    """
+    md = Markdown(
+        extensions=[
+            "meta",
+            "fenced_code",
+            "codehilite",
+            "smarty",
+            MarkdownLinkExtension(),
+        ],
+        output_format="html",
+    )
+    return md
+
+# to this...
+
+def markdown_factory() -> Markdown:
+    """Create a Markdown instance.
+
+    This method exists only to ensure we use the same Markdown instance
+    for tests as for the actual thing.
+
+    Returns
+    -------
+    markdown.Markdown
+
+    """
+    md = Markdown(
+        extensions=[
+            "footnotes",        # Add footnotes support
+            "pymdownx.tilde",   # Add strukethrough support
+            "meta",
+            "fenced_code",
+            "codehilite",
+            "smarty",
+            MarkdownLinkExtension(),
+        ],
+        output_format="html",
+    )
+    return md
+
+```
+
+That's fuckin' it. But, to actually get this package into my automation pipeline, I have to do a couple things. I can't just open an issue or make a pull request on github, because I uhm.... don't *have* a github account. So the process looks something like this:
+
+1. Create my own fork of blag hosted on my gitea
+2. Change the fork to have my modifications
+3. Change the build process, as the current process uses a `Makefile` which I do not understand nor care to use. I'd rather use a `setup.py` file and pipenv.
+4. Upload the build to my private package repo
+5. Configure my workflow to allow pipenv to grab from my private repo
+
+This isn't my first rodeo with setting these things up, though. I've got a similar build pipeline going for another private python package i call `bootleg-jwt`. Most everything is actually taken care of for me in the config files in that project. The difficult spots will be steps 1 and 5. The fork is a slight annoyance because I need to first create a new gitea organization, move blag to *it*, and *then* fork it. Its currently mirrored directly to my user profile as `freyja/blag` but I can't fork from a repo that my user already owns.
+
+Okay. Enough talk, already! Lets do this!
+
+## Actually doing the thing
+
+So all that stuff I was talking about before was more-or-less me brainstorming what I needed to do. Here's some reporting back from me doing the stuff.
+
+### Getting my fork on my package repo
+
+Turns out, the makefile is fine. Super easy. Just gotta hit it with a `make` command and its primo. So what I did, was I made the mirrors org and moved my blag mirror over there. Then I forked it to my personal gitea account. Then I cloned the fork, and made a `v2.3.0` branch because it was on `v2.2.x`. I updated the version in the source. Then I added the dependency for the new package `pymdown-extensions` in the appropriate files. Then I modified the `markdown.py` file to include the `footnotes` and `pymdownx.tilde` (strikethrough) extensions. Then I ran the makefile, which did its magic and made the stuff. Then I simply run twine to upload to my personal gitea package repo. Done. Version 2.3.0 is on my repo.
+
+As far as updating the workflow: In getting pipenv to grab from my private gitea repo, I've had to insert a couple environment variables into my pipfile. That's convenient. I can simply add them to the workflow like so:
+
+```yaml
+
+      -
+        name: Install pipenv, build blog...
+        env:
+          PIPENV_USER: ${{ secrets.PRODUCTION_REGISTRY_USERNAME }} #ADDED
+          PIPENV_PASS: ${{ secrets.PRODUCTION_REGISTRY_TOKEN }} # ADDED
+        run: |
+          pip install pipenv
+          pipenv install
+          pipenv run blag build
+
+```
+
+And that should take care of it.
+
+You'll know this has worked when:
+
+1. You can see this blog post
+2. ~~strikethrough text works~~
+3. footnotes[^1] work.
+
+---
+
+__END TIME: 2024-01-18 02:48__
+
+---
+
+[^1]: Footnotes are these thingies right here.