Use last available version when "latestVersion" doesn't exist for a platform

[codefromthecrypt]

Is your feature request related to a problem? Please describe.
Right now, there are two scenarios which hurt usability unnecessarily

• homebrew-core isn't up-to-date, so there's a version available for linux, but not darwin
• someone tries to use 1.19_debug and the message is imprecise

homebrew-core out of date

Right now, the envoyproxy project doesn't sync homebrew as a part of their release. This means windows and linux are available before darwin. Currently, we delay archiving envoy for all platforms until this darwin is available. Otherwise, people freshly using func-e will not be able to because when latestVersion won't be available for darwin/* platform.

trying 1.19_debug on something besides linux

Currently, archive-envoy only has a source of debug releases for linux. If you try on darwin you'll get an imprecise message.. that lastestVersion isn't available instead of no versions are available

ENVOY_VERSIONS_URL=https://archive.tetratelabs.io/envoy/envoy-versions_debug.json ./build/func-e_darwin_amd64/func-e run -version
error: couldn't find version "1.19.1_debug" for platform "darwin/amd64"

Describe the solution you'd like
In both cases, we would be better off looking for the last available version when latestVersion is not available. This allows decoupled platform availability. For example, 1.20.0 can release for linux/* and darwin/* later. By searching, we can also know that a platform isn't available at all. For example, windows/arm64 wouldn't be in any of the published lists. https://archive.tetratelabs.io/envoy

Care should be taken to not spam the user. We should still alert the user that we are looking up the latest version, just that the implementation of this prioritizes latestVersion from the json schema, but silently looks up the last available one if that fails. Upon failure, if no versions at all are available, we should have a better message.

Watch the edge cases in impl:

• Major updates: Ex. latestVersion is 2.0.0, but the last version available for darwin/amd64 is 1.19.1
• Minor updates: Ex. latestVersion is 1.20.0, but the last version available for darwin/amd64 is 1.19.1
• Patch updates: Ex. latestVersion is 1.20.10, but the last version available for darwin/amd64 is 1.20.9
• No versions available Ex. latestVersion is 1.19.1_debug and there are no versions available for that platform.

Describe alternatives you've considered
Not doing anything, but it is very common darwin is delayed, and most of our users are on linux. It isn't fair to block everyone and unlikely this situation will become better soon.

Additional context

• request for envoyproxy to do homebrew on their own Automate updating the homebrew (os/x macos darwin) formula envoyproxy/envoy#17500
• example late pull request to release envoy on darwin Envoy 1.20 Homebrew/homebrew-core#86755

[codefromthecrypt]

I opened this discussion on homebrew about reducing the delay and effort to get os/x available, but I wouldn't expect the result to be fast even if they dropped linux.

There are still perpetual problems in the bazel build and many things aren't backported, which means patches and whatnot. The perpetual lack of arm64/m1 for os/x means re-explaining why it doesn't work on each homebrew release. Removing linux probably will cut a day, but the delay magnitude will likely remain in days. Hence, we should still implement this.

[codefromthecrypt]

I think we'll have to do this soon and expect osx builds of envoy perpetually delayed. I can't stomach the constant battles every release to try to trim the delay from week plus to days.

For example, the last change basically the only way to know it would break is to run it on linux, but normal linux the build doesn't really finish on either. You'd have to either pray it just works or run the ancient homebrew/ubuntu16.04 image and hope that matters somehow. To do that requires many hours of effort more than just testing os/x.

I really have appreciated @carlocab support, but honestly I feel let down about the whole thing. I feel the context of linux formula has become more important than if anyone uses it, and more important than constantly frustrating people like me with heavy labor. That's a con of community at the end which is that the overall opinion might not be a good fit for you personally. I know I can't handle the swimming fleetingly uphill especially knowing when that reducing the pain isn't allowed. So basically, I'm throwing in the towel.

Impact here and the shorter version is that we need to design for skew as it is no longer appropriate to hold everything back until os/x works. Upstream prioritizes linux, so that's out immediately. Implementing this change will let linux go ahead of os/x, and we'll just have to do two releases.. once when the release is out and again whenever the homebrew becomes unbroken naturally.

[carlocab]

@codefromthecrypt I sympathise with your frustration, and I'm sorry you haven't had a good experience with this. I hope you'll still consider continuing to contribute to Homebrew/core. Contributors like you are invaluable.

We'll do our best to make your contribution experience better. Would it help if you had a CI setup that more closely mirrors what we do on Homebrew/core, rather than trying to fix it for yourself locally?

[codefromthecrypt]

@carlocab what I mainly want is the chance to succeed. I think you understand there is unnecessary tech debt in that recipe. Even if it takes hours for my laptop to finish os/x it takes longer for the homebrew test bot to do that. That means to prevent lost days, I have to run locally all the verifications that would occur upstream. The problem as I described is that linux is here and it breaks, and last time it caused multiple glitches. People who maintain linux don't seem to want to make comments about things they find obvious, yet those are also the things that break. For example, why putting brew's path in front doesn't end up with brew's python3 there. There's also the tech debt of duplication, like the version of python being in two places over this, and it is only for linux.

To test locally is doubling the time actually more because my laptop can't effectively run darwin build at the same time as ubuntu via docker. So I have to basically plan an afternoon. If I don't, then I have to wait for the linux brew bot to fail which basically means check the next day. Any CI will be slower than my laptop, I would guess, and I feel like this is really just adding more burden around an obviously bad choice, which is to retain that linux dimension.

[codefromthecrypt]

@carlocab Since I have your attention, the other thing that completely demotivates me are comments like a week delay is somehow good. This only works in a position where there is no competition, and a sentiment such as things are worse elsewhere is dismissive and makes me not want to work in that environment. Of course I will help in maintenance on things unlikely to take a long time or break, such as func-e's recipe. Delays aren't 1 week there either, and there isn't any problem with that. If I respect myself, I can't figure how I would intentionally want to sacrifice my time because someone thinks it is ok to have to check things and redo them for days on end. That's a horrible cultural pov.

[codefromthecrypt]

anyway I hope the meatgrinder between envoy release and homebrew gets better, as if it isn't me in the middle someone else would be, and that still sucks.

Meanwhile, I digressed enough.. I'll update this issue with some decoupling which can reduce pressure here.

[codefromthecrypt]

this is probably a higher priority albeit related. Right now, figuring out where the envoy version is has some nuance to it. Automating this will lower the skill level required to archive macOS tetratelabs/archive-envoy#21

[codefromthecrypt]

To be clear on impact of this, it is around latestRelease, which is currently 1.20.0. So when envoy releases patches like 1.18.5 it shouldn't hurt anyone. However, 1.20.1 will for fresh installations. I don't expect that to be out soon, but we also need func-e available before that occurs, so fixing this and releasing it ahead of 1.20.1 will allow decoupling and without a poor experience.

[codefromthecrypt]

I think we shouldn't update LastKnownEnvoy constant unit that patch is available for all supported platforms. This also helps in e2e tests as the inconsistency hurts us there. For example, we have complex logic and extra downloading in TestFuncEUse_MinorVersion which dodges the inconsistent version case, presumably because at the time it was written, macOS was behind. This causes every single commit to download more versions which hurts CI and also people like me in slow hotel network.

In fact, I think we should entirely ignore the "latestVersion" key for new versions of func-e at runtime. We always search for either the latest available patch generally, or the latest patch for a given minor version for the current platform.

Because it would be ignored, this means that the json key "latestVersion" might be overrun. However, we haven't defined it as a control anyway. In any case, if someone doesn't want search-style behavior, they already have a means to pin a minor or a specific patch. If later we need to limit the search to max out at the "latestVersion" key, we could, but I prefer to not add logic around that now. @mathetake wdyt?