Latest News
Migration
Meanwhile the software project migrated from the old incubator repository to the new dedicated repository diy-gnupg. To make things easier, there is a migration script for repository cloning provided. Please adjust the localdestinationpath to your preferences or run
$ git clone https://codeberg.org/fmg/diy-gnupg.git
from an appropriate folder of your choice.
User Settings
Now it is very easy to override the chosen GnuPG version numbers in etc/local.conf. This wil be useful if the repository is out of sync with upstram versions.
Logging
The repository provides a folder log/ which is convenient to have. The c&p examples in the README were adjusted.
Local Notes
The repository ignores a folder local/ which is convenient to have for some notes. These notes will not interfere with the Git repository setup (i.e. they do not appear as e.g. new or modified files).
Situation
Last time I presented the second script for unpacking the source code together with a refactored code structure. This allows to include (in shell terminology: source) external files, i.e. the configuration and an error library for shared usage among different scripts. The configuration file itself sourced a local configuration file with user settings - kind of an ugly construct. And to make things worse, each script was supposed to source those two files. Coming up with the idea of introducing a function library independent from the error library, this would require to source a third file and put the code into each script. Guess what I thought! Something felt wrong - time to pull the emergency brake.
Code Design
Continuing this path wasn't an option because it would pile up technical debt. This will eventually increase maintenance time to an extend that the project consumes too much time working on it at all, meaning it's dead. Even the revamp of two scripts and the configuration file was annoying, but the prospect of a flexible code structure was worth the effort. I introduced a single adapter file to be sourced by the scripts, and this can be extended to future needs without touching countless files. The habit of duplicate code usage is considered to be an anti-pattern, and this is for good reasons. It is quite obvious that this idea was inspired by the adapter pattern. The surprising part from my point of view was the fact that I didn't expect it becoming that important let alone that fast in shell programming. At the time I introduced the adapter the project consisted of four relevant files, and it was already refactored three days earlier.
The Function Library
The code is already prepared to use another library in the near future. This will make the shell scripts smaller and IMHO better readable, and it will be possible to reuse functions without code duplication. Another revamp of the two shell scripts is still necessary, together with the environment setup. This is expected to be no big deal.
First Steps
The corresponding paragraph from last time still holds unchanged. But we are approaching this milestone.
WP: Technical debt
WP: Duplicate code
WP: Anti-pattern
WP: Adapter pattern
To be continued...