bin ensure should ensure versions match the target config file.

[marcosnils]

from @einarpersson:

I really love this tool. I have started to migrate many binaries to use bin on my laptop. Now I want to share the same configuration file (in my dotfiles repo) with my home server. But I am struggling with how to keep them in sync, for example after updating (and pushing the changed config) on one computer, how can I then ensure the installed tools are of the same version on the other? I want to pull the latest changes which updates my bin config, and at time the config and reality does not match. But if I run bin ensure or bin update -a nothing happens.

What I am missing is something like:
bin ensure --version that both looks at IF the tools is there, and IF it has a matching version. And if not, the user can then go ahead and update it. Actually, i'd prefer if bin ensure by default also checks version, and perhaps has a flag --ignore-version.

I would like a workflow like this:

Computer A: bin update foo
Computer A: git add, commit, push xyz
Computer B: git pull xyz
Computer B: bin ensure (updates/reinstalls binary foo of matching version, given what is specified in config)
Today as far as I can tell, the fourth step would just say nothing, indicating that everything is fine. And if I run bin update -a it would say that everything is up to date, since the config is up to date (but the actual installed tool is out of date, not matching the config).

Opening this issue as a follow-up of #204. As described in the title, bin ensure should also make all the binaries match the config file specs

[marcosnils]

seems like in order to implement something like this, we'd need some sort of bin.lock file which contains at least the path, md5 and version of the binary. Otherwise, there's no way for bin to know which "supposedly" is the current installed version of the binary.

As a stopgap, I can implement this feature relying in the hash field of the config.json file but it's not the best solution. This also made me realize that the current hash field in the config.json has never been properly implemented. I'll craft a PR to address both of this shortcomings as a first step and we can then move from there.

[marcosnils]

@einarpersson this should have been addressed in the new release v0.18. LMK if that works for you.

Keep in mind that running bin ensure the first time will re-install all your current binaries to fix the incorrect hash issue described in this commit: 02eb5bb

[einarpersson]

@marcosnils Looks good so far, I'll let you know otherwise! Great work! 👏