I believe inlining is a better way to go. This is already being done for the default config:

https://github.com/makeworld-the-better-one/amfora/blob/86bde5ec11c26b58d4428c7c57941d85679a07b1/config/default.go#L3

https://github.com/makeworld-the-better-one/amfora/blob/86bde5ec11c26b58d4428c7c57941d85679a07b1/config/default.sh#L1-L10

Ideally the inlining would happen with the stdlib embed package, but that's only going to be available in Go 1.16. There are other Go inlining solutions, like go-bindata. That method has a question. Do I check in the generated code, and tell other developers to regenerate it if they need? Or do I add it as a build step in the Makefile? The latter is nicer, but then all the repo packages that don't use the Makefile, just the custom go build command, need to be updated. And then they won't be able to build the package until they update. It also adds a build-time dependency, something Amfora currently doesn't have.

I'm not sure what the best solution is. What do you think?

Generally, I don't like to inline stuff like that but I guess it's the Go way of doing things...

I didn't know about embed (I'm still really new to Go, sorry) but that would seem like the right fit for this as it would be integrated into the normal build process and thus not require packagers to do anything special.

go-bindata seems to only do what your default.sh does for the config, so what would be the point? Generated files should not be checked in IMO but I understand that you don't want to make this more complicated for packagers.

So: For now, I will update this PR to just inline README and THANKS.md. Once Go 1.16 hits, it can be refactored into using embed.

I inlined the files in the same manner as you did it for the default config.

go-bindata seems to only do what your default.sh does for the config, so what would be the point?

You're right, it's just the same. Not sure what I was getting at.

So: For now, I will update this PR to just inline README and THANKS.md.

Thanks!

Once Go 1.16 hits, it can be refactored into using embed.

Unfortunately that's not an option, as I like to support some of the slightly older versions of Go, as I believe many people compile Amfora themselves, and will not always have the latest version.

Ah, ok, I was slightly confused about the go:generate directive because the shell scripts already generate the code. It seems weird to me to not just call the shell scripts... what is the benefit of using the Go CLI? But anyway, I changed it so that the two new files can be regenerated using go generate as well.

Sorry! You're right of course, the about pages were unnecessarily recreated. I fixed that and moved the creation code to a separate file (and added the version page to that as well). In display.go's Init function I added a call to the new aboutInit that creates these pages once.

Anything else?

what is the benefit of using the Go CLI

It means that running go generate ./... will generate everything. Maybe in the future things will be done differently, with different scripts. But you can always use that command to generate everything.

I changed it so that the two new files can be regenerated using go generate as well.

It still doesn't work actually. I fixed it though, see 819a6cf.

The way you create about pages seems very clean. Thanks for your work! Merged, with some of my own small fixes.