Simple 'upgrade' heuristic (for binaries, not ubi itself)

[ELLIOTTCABLE]

It'd be nice to have a super-slim "upgrade the binary" mode that doesn't touch it if it's up-to-date, preforming only the GitHub API call to get the latest release.

I think the lightest-weight way to do this would be to require the invoker to provide the value to compare against; something like:

ubi -p beeper/bridge-manager -i "$XDG_BIN_HOME" --rename-exe "bbctl" --update-unless-at "$version" --verbose

... basically just the inverse of --tag; instead of "install this version", it's "install if latest is not this version."

[autarch]

This would be useful, but how would ubi know what version was currently installed? Ideally, every binary would support a --version flag, but we can't really count on that.

[ELLIOTTCABLE]

That's precisely what I was saying in my O.P. - instead of a full-featured "upgrade" flag, provide the barest-bones "make the CURL request, then do nothing if the remote version precisely equals <given string>."

That shifts the responsibility of finding and parsing the existing version number from the existing installation downstream into the consuming tool or script; which is really the best ubi can ever possibly do, because there's simply no standard. (=

i.e. ubi's only responsibility here is 1. the GitHub API curl-request it's presumably already making, and 2. a string-comparison against the CLI flag given, however the user may have gotten that string.

[autarch]

Doh, sorry, I didn't read this carefully enough.

This would definitely be easy to add. I do wonder if it's worth the trouble, though. In my use cases, I'm mostly downloading things that are a few megabytes (c. 5-50), which is pretty fast. Can you elaborate on why you want to avoid re-downloading things a bit? Are you using this to download much larger tools, or working in a more bandwidth-constrained environment?

[ELLIOTTCABLE]

My thought is less about the downloading, and more about the overwriting:

1. without certificate checks (or, as brought up in ubi should verify checksums by default #84, with most binaries not publishing certificates at all), it seems better from a security standpoint to stick with "the devil you know." Let's examine the two possibilities:

   A. You download a 'good' executable for the same apparent version, whereas you previously had been MITM'd with a 'bad' one. In this case, any damage it was going to do is probably already done; once an actor has attained access, there's no way they're going to rely on the initial vector. They'll have set up additional maintenance vectors, so removing this one gains you nothing.

   B. You download a 'bad' executable for the same apparent version, whereas you'd previously had a 'good' one. Well, this is obviously bad.

2. I'm not sure how various processes may react to having a possibly-running binary switched out from underneath them. I imagine this is a niche concern; but again, why run the risk?

tl;dr it's less about network waste and more about stability: don't change things that don't need to be changed, and you have less opportunity for chaos to enter the system.

(So, both niche concerns; hence me thinking "let's keep the related feature to its absolute bare-bones minimum.")

[autarch]

Good points re: security.

Regarding #2, I don't think this is really an issue outside of some very weird scenario. On most platforms, you can simply replace a running executable's file and nothing happens, because the executable is already in memory, and as long as the executable doesn't attempt to read its own file (why?!) there's no relationship between what's running and what's on disk.

On Windows, you simply cannot replace a running executable, which is annoying. There's already some special-casing for this in ubi's --self-upgrade handling, for reference.

I will continue to think about this. I'm a bit concerned about the scope of ubi expanding a bit too much. It's great that people are using it more, but at a certain point I have to say "I think you want a package manager instead".

[ELLIOTTCABLE]

"Out of scope" is my favourite response from a maintainer. It's like paying actual money from your actual pocket for software: reassures you that the thing you're relying on there will be there, and be reliable, for much longer.

You do you boo, 💜