Picture says it all.
I’ve got an ini style configuration I’ve been using where I’ll specify in one place the expected version of an application for the version checks, and then a command in bash that can be used to extract the version in a pretty distro-independent way.
It’ll work like this but when given to the users it would make more sense to use an object notation that self contains each section into the application version check.
This should also make downstream providers a little happy as they can now have their pretty gui window to edit the file without having to stress over the structure of the ini file being intact.
I am still deciding if this is the best way. I would like to be able to provide more version commands than application tests, or at least make it able to be used that way so that if users want to add existing commands, there will be a bit of a repo to use so that they dont have to go pruning versions every time they add a check. This obviously would not be useful unless someone mapped out the whole gnu toolchain.
Now that this is being done in python in this manner where I can still use the shell for extraction of version information there are lots of very useful options that bash would not be able to do quite as easily for the user without great pain on my part.
Yeah that’s a lot cleaner.
Super clean, super fast. Now individual tests can be added rapidly without all the bash boilerplates, the output is self generating, and unit tests are being added in the configuration instead of coding out every single little piece. The environment variable checking and setting will follow suit, but remediation of failed checks for env variables may require the user to exit the shell and come back — still looking at it since I am pretty sure I will run into issues with the fact that a subshell is being opened. I think I could probably bootstrap into the env var checks by sourcing a calling bash script to the python app, but I’ll need to analyze it a little more for efficacy.