Suggestion: allow basic templating in `ArchiveName` & `ExecutableName`

[axllent]

Certain projects use the release tag in the archive name, eg awesome-package_0.1.2_linux_amd64.tar.gz, and I seem to recall some that even use it in the binary name too (not that I think the latter is a good idea).

My suggestion is to allow some basic go templating on both the Provider ArchiveName and Updater .ExecutableName of at least some common variables, such as {{.Tag}} {{.GOOS}}&{{.GOARCH}}. Whilst certain variables can be generated before the request (runtime.GOOS&runtime.GOARCH`), others are dependent on the remote info.

u := &updater.Updater{
    Provider: &provider.Github{
        RepositoryURL: "github.com/user/awesome-package",
        ArchiveName:   `awesome-package_{{.Tag}}_{{.GOOS}}_{{.GOARCH}}`,
    },
    ExecutableName: "awesome-package_{{.Tag}}",
    Version:        "0.1.1",
}

This would of course still remain completely backwards compatible with the current system, and one could even mix the two: ArchiveName: fmt.Sprintf("awesome-package_{{.Tag}}_%s_%s.tar.gz", runtime.GOOS, runtime.GOARCH).

The backstory is I've been meaning to rewrite a simple GitHub binary updater I wrote some time ago (far more primitive than yours), although I have been putting it off while I collect ideas etc. I just came across go-rocket-update which I think has a lot of potential, so rather than me spend time rewriting mine from scratch, I'd first check to see if you were open to suggestions to yours instead? I also have some other suggestions too if you're open to it.

[mouuff]

Thank you for the suggestion! Yes I think it could be a good idea! Today what you can do is call the provider by yourself to get the version (and then the updater) but I agree that variables would make things a lot easier :)

Implementation:

I think we should add the whole templating logic outside the updater. The updater would just use an interface to get the variables. We would have a default implementation for the basic {{.Tag}} {{.GOOS}} {{.GOARCH}} variables, and if a dev wants to add his own variables then he could make his own implementation of that interface.

[axllent]

I hadn't considered running it twice as an interim workaround, although I haven't implemented go-rocket-update yet in anything as I'm still in the testing phase, and seeing where this project is headed. I think that your implementation proposal makes good sense though, and hopefully doesn't add too much bulk or complication.

[mouuff]

Not exactly running it twice, just running the provider to get the latest version, then setup the updater with this information. But indeed GetLatestVersion will be called a second time by the updater. I m not afraid of the bulk/complications. It's just another interface. But fell free to make a PR with your own implementation :)

[mouuff]

Here is a workaround for now. Example with ticker:

func selfUpdate() (updater.UpdateStatus, error) {
    provider := &provider.Github{
        RepositoryURL: "github.com/achannarasappa/ticker",
    }
    latestVersion, err := provider.GetLatestVersion()
    if err != nil {
        return updater.Unknown, err
    }
    if len(latestVersion) > 0 {
        latestVersion = latestVersion[1:] // removes the 'v' prefix to match github archive
    }
    provider.ArchiveName = fmt.Sprintf("ticker-%s-%s-%s.tar.gz", latestVersion, runtime.GOOS, runtime.GOARCH)
    u := &updater.Updater{
        Provider:       provider,
        ExecutableName: "ticker",
        Version:        c.Version,
    }
    return u.Update()
}

[mouuff]

I think I will try to find some time this or next month to implement that. except if you fell like making a PR :) I think it could be a great addition!

[axllent]

It's unlikely I'll be able to spend much time on this in the next two months as well, as I just returned to work last week after a shoulder operation two months ago (long recovery, and now a huge backlog of work to catch up on). This was actually the main reason I was looking for existing self updater modules last week, as I just don't have the time to reinvent the wheel right now again :-) I'm also not in any rush either. If I do manage to spend some time on it I'll let you know though!