Some time ago I started using safekeeper in order to capture certain environment variables and embed them into my code (as template). Safekeeper is an obvious solution to a common problem so I was glad I did not have to implement rev 1. But once I started to review the code I realized some of the risks of 3rd party libraries, however, I was grateful safekeeper was only one small .go file.Looking at the code I saw what I expected. All of the necessary code to perform the task at hand. A program that had a few parameters that hinted to the input and output of the task of string replacement. But what I also found was the inclusion of an additional package called or from kingpin. It was a command line parser package.I looked at safekeeper from all directions trying to figure out what it was “exactly” that kingpin’s CLI was doing better than the standard flag package. I could not find anything. Not even in the leftmost use case. So I forked safekeeper and implemented the CLI flags with the stdlib version.Upon further reflection I have decided that I hate the implementation of the original safekeeper. Here is a sample://go:generate safekeeper –output=appsecrets.go –keys=CLIENT_ID,CLIENT_SECRET $GOFILE What makes it hideous is the “keys” parameter. The provided go:generate command executed the safekeep program and passes the subsequent parameters. One such parameter, keys, tells safekeeper which environment variables to use in the template. Then the code prefixes the keys with a string “ENV_” and then performs a number of string replaces in the template provided in the input param.dumb dumb dumb.(a) the stdlib already includes a template function(b) it’s easy to have collisions regardless of implementation(c) why specify the keys and not use the entire ENV anyway, as-isSo the next time I have a swipe at safekeeper it’ll be something like envtmpls or something like that… where one only specifies the input and ouput files and all of the data comes from the environment.